[jira] Updated: (TUSCANY-2251) Problem with 1.2 RC4 with simple JavaBean

[Nishant Joshi (JIRA)]

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

Nishant Joshi updated TUSCANY-2251:
---

Attachment: generatedClientCode.zip

I m using TopDown approch to generate proxy from wsdl
i have WTP version 1.0.101, JST version 1.0.2, WST version 1.0.2, and Axis only 
(not Axis2)

> Problem with 1.2 RC4 with simple JavaBean
> -
>
> Key: TUSCANY-2251
> URL: https://issues.apache.org/jira/browse/TUSCANY-2251
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Data Binding Runtime
>Affects Versions: Java-SCA-1.2
> Environment: Eclipse 3.3, Tuscany SCA 1.2 - RC4
>Reporter: Nishant Joshi
> Fix For: Java-SCA-1.2
>
> Attachments: generatedClientCode.zip, SimpleBeanProblem.zip
>
>
> Hi there,
> I have one sample which was perfectly working with 1.0 incubating... when i 
> have tried same with 1.2 RC4 all the data come from client was null for all 
> the values for a simple bean.
> Please note that I m creating Client on Eclipse 3.3... using WebService 
> client generation facility of eclipse...
> I m attaching detail for more detail...
> When tried same with SCA client it was giving me perfect result... 

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

[jira] Closed: (TUSCANY-2253) TuscanyServletFilter cannot be initialized when no display-name is specified in web.xml

[Ilya Kanonirov (JIRA)]

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

Ilya Kanonirov closed TUSCANY-2253.
---

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

This issue is reproduced exactly in Java-SCA-1.1. Version 1.2 seems to be free 
from it.

I am closing the issue. Thanks!

> TuscanyServletFilter cannot be initialized when no display-name is specified 
> in web.xml
> ---
>
> Key: TUSCANY-2253
> URL: https://issues.apache.org/jira/browse/TUSCANY-2253
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Web App Integration
>Affects Versions: Java-SCA-1.1
>Reporter: Ilya Kanonirov
> Fix For: Java-SCA-1.2
>
>
> When the display-name element is not specified in web.xml, 
> TuscanyServletFilter fails to initialize with the following exception:
> 16:27:52,393 ERROR [[/]] Exception starting filter tuscany
> java.lang.NullPointerException
> at 
> org.apache.tuscany.sca.host.webapp.WebAppServletHost.init(WebAppServletHost.java:209)
> at 
> org.apache.tuscany.sca.host.webapp.TuscanyServletFilter.init(TuscanyServletFilter.java:51)
> at 
> org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:225)
> at 
> org.apache.catalina.core.ApplicationFilterConfig.setFilterDef(ApplicationFilterConfig.java:308)
> at 
> org.apache.catalina.core.ApplicationFilterConfig.(ApplicationFilterConfig.java:79)
> at 
> org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:3540)
> at 
> org.apache.catalina.core.StandardContext.start(StandardContext.java:4110)
> at 
> org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:759)
> at 
> org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:739)
> at 
> org.apache.catalina.core.StandardHost.addChild(StandardHost.java:524)
> 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)
> ...

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

[jira] Updated: (TUSCANY-2260) Validation Testcases Part -2

[Hasan Muhammad (JIRA)]

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

Hasan Muhammad updated TUSCANY-2260:


Attachment: validation2.patch

> Validation Testcases Part -2
> 
>
> Key: TUSCANY-2260
> URL: https://issues.apache.org/jira/browse/TUSCANY-2260
> Project: Tuscany
>  Issue Type: Test
>  Components: Java SCA Integration Tests
> Environment: All
>Reporter: Hasan Muhammad
>Priority: Minor
> Attachments: validation2.patch
>
>
> Hi Simon,
> I have attached a patch for a second set of validation test cases. With this, 
> there should be a total of 22 testcases running. Please review and commit. 
> Let me know if there is any problem with the patch
> Hasan

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

Re: How do you plug in validation monitoring?

[Hasan Muhammad]

Hi Simon,

I opened JIRA 2260 and attached a second batch of validation test cases.

regards
Hasan

On Tue, Apr 22, 2008 at 8:16 AM, Hasan Muhammad <[EMAIL PROTECTED]> wrote:

> Hi Simon
>
> I opened JIRA 2255 and attached a patch for the new testcases.
>
> Hasan
>
>
> On Fri, Apr 18, 2008 at 12:58 PM, Simon Laws <[EMAIL PROTECTED]>
> wrote:
>
> > On Thu, Apr 17, 2008 at 5:44 PM, Simon Laws <[EMAIL PROTECTED]>
> > wrote:
> >
> > >
> > >
> > > On Thu, Apr 17, 2008 at 5:02 PM, Hasan Muhammad <[EMAIL PROTECTED]>
> > wrote:
> > >
> > > > Hi Simon,
> > > >
> > > > We should have an api for plugins to provide a resource bundle. This
> > api
> > > > probably needs to be on the monitor or somewhere, i am not sure. But
> > the
> > > > scenario occurs when plugins want to use the default Monitor but
> > still
> > > > want
> > > > to use their own resource bundle for messageIDs.
> > > >
> > > > regards
> > > > Hasan
> > > >
> > > > On Wed, Apr 16, 2008 at 3:30 PM, Hasan Muhammad <[EMAIL PROTECTED]>
> > > > wrote:
> > > >
> > > > > Hi Simon,
> > > > >
> > > > > I looked at the new Monitor and Problem interfaces. What do
> > > > getMessageId()
> > > > > and getMessageParams() actually return? is MessageId a way to
> > > > categorize the
> > > > > error message?
> > > > >
> > > > > regards
> > > > > Hasan
> > > > >
> > > > >
> > > > > On Tue, Apr 15, 2008 at 10:59 AM, Hasan Muhammad <[EMAIL PROTECTED]
> > >
> > > > wrote:
> > > > >
> > > > > > Hi Simon,
> > > > > >
> > > > > > I was wondering if i can cook up some validation test cases if
> > they
> > > > do
> > > > > > not exist. Or should we wait until the monitor issue is resolved
> > ?
> > > > > >
> > > > > > Hasan
> > > > > >
> > > > > >
> > > > > > On Thu, Apr 10, 2008 at 4:34 PM, Hasan Muhammad <
> > [EMAIL PROTECTED]>
> > > > > > wrote:
> > > > > >
> > > > > > > Hi Simon,
> > > > > > >
> > > > > > > I dont think using an underlying tuscany jdk logger would be
> > > > useful to
> > > > > > > plugins as they may not want to log, rather show it somewhere
> > else
> > > > such as
> > > > > > > console etc. Tuscany can use an underlying logger in it's own
> > > > monitor ( as
> > > > > > > it uses today). But i think the first approach of using a
> > monitor
> > > > is better
> > > > > > > along with the condition that it be made more usable by the
> > > > plugins by
> > > > > > > giving them greater control.
> > > > > > >
> > > > > > > Another point is that tuscany should use ResourceBundle for
> > > > validation
> > > > > > > messages as well. I dont think this is being done today.
> > > > > > >
> > > > > > > regards
> > > > > > > Hasan
> > > > > > >
> > > > > > >
> > > > > > > On Wed, Apr 9, 2008 at 1:22 PM, Simon Laws <
> > > > [EMAIL PROTECTED]>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > On Wed, Apr 9, 2008 at 12:49 PM, Simon Laws <
> > > > > > > > [EMAIL PROTECTED]>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Wed, Apr 9, 2008 at 12:00 PM, Hasan Muhammad <
> > > > [EMAIL PROTECTED]>
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > Hi Simon,
> > > > > > > > > >
> > > > > > > > > > I am on revision 634808. The ContributionServiceImpl has
> > > > changed
> > > > > > > > since
> > > > > > > > > > then,
> > > > > > > > > > and with the one that i have, it would lead through the
> > > > > > > > > > CompositeProcessor
> > > > > > > > > > instead of the CompositeDocumentProcessor. Hence the
> > > > difference
> > > > > > > > in
> > > > > > > > > > exceptions..
> > > > > > > > > >
> > > > > > > > > > Also, dont you think that with the error that you got
> > should
> > > > > > > > throw an
> > > > > > > > > > exception with schema validation, rather than just a
> > > > warning?
> > > > > > > > > >
> > > > > > > > > > Hasan
> > > > > > > > > >
> > > > > > > > > > On Wed, Apr 9, 2008 at 6:36 AM, Simon Laws <
> > > > > > > > [EMAIL PROTECTED]>
> > > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > On Tue, Apr 8, 2008 at 2:58 PM, Hasan Muhammad <
> > > > > > > > [EMAIL PROTECTED]>
> > > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > > Hi Simon,
> > > > > > > > > > > >
> > > > > > > > > > > > Thank you for the good information. First up i am
> > trying
> > > > to
> > > > > > > > verify
> > > > > > > > > > > whether
> > > > > > > > > > > > the schema validation works when we point to our
> > > > schemas.
> > > > > > > > Can you
> > > > > > > > > > let me
> > > > > > > > > > > > know what is a simple error that i can introduce so
> > that
> > > > i
> > > > > > > > can
> > > > > > > > > > verify
> > > > > > > > > > > > this?
> > > > > > > > > > > > I tried doing this to my composite file (In block
> > red):
> > > > > > > > > > > >
> > > > > > > > > > > >  
> > > > > > > > > > > > > > > > > > > > > > class="mysca.test.myservice.impl.MyServiceImpl"/>
> > > > > > > > > > > >**
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >  
> > > > > > > >

[jira] Created: (TUSCANY-2260) Validation Testcases Part -2

[Hasan Muhammad (JIRA)]

Validation Testcases Part -2


 Key: TUSCANY-2260
 URL: https://issues.apache.org/jira/browse/TUSCANY-2260
 Project: Tuscany
  Issue Type: Test
  Components: Java SCA Integration Tests
 Environment: All
Reporter: Hasan Muhammad
Priority: Minor


Hi Simon,

I have attached a patch for a second set of validation test cases. With this, 
there should be a total of 22 testcases running. Please review and commit. Let 
me know if there is any problem with the patch

Hasan

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

Reg: BPEL support in Tuscany

[Ashwini Kumar Jeksani]

Hi Luciano,

My name is Ashwini. I'm interested in contributing to BPEL support in Tuscany. 
From the mailing list I came to know that you have already done quite some work 
on this. Please let me know if there are any areas in which I can contribute.

Thanks & Regards
Ashwini Kumar Jeksani



 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***

[jira] Created: (TUSCANY-2259) Multiplicity for heterogeneous bindings not working

[Mario Antollini (JIRA)]

Multiplicity for heterogeneous bindings not working
---

 Key: TUSCANY-2259
 URL: https://issues.apache.org/jira/browse/TUSCANY-2259
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Assembly Model
Affects Versions: Java-SCA-1.2
 Environment: Maven version: 2.0.8
Java version: 1.6.0_05
OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows"
Reporter: Mario Antollini


Hello,

I have been trying to make the catalog of store-market to be referencing 
targets with heterogenous bindings (by means of multiplicity)

The following reference (two targets using the same binding) works fine:







At runtime, the goodsCatalog gets "populated" with both vegetables and fruits.

However, I could not get goodsCatalog to be populated with the same items when 
using heterogenous bindings. I was trying with a local FruitsCatalog and a WS 
VegetablesCatalog.

I tried:

1 - Approach 1:









Result: 
Only fruits were obtained. Thus, the local binding was working but the web 
service one was not.

2 - Approach 2:









Result:
Only fruits were obtained. Thus, the local binding was working but the web 
service one was not.

3 - Approach 3







Result:
Nothing was obtained in the catalog.

4 - Approach 4





Result:
Nothing was obtained in the catalog.



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

Vtests failing in latest builds?

[Mike Edwards]

Folks,

I'm getting a vtest failure in my latest builds - any explanation?

---
 T E S T S
---
Running 
org.apache.tuscany.sca.vtest.javaapi.annotations.scope.ScopeAnnotationTe

stCase
atScope1 - Setting up
22-Apr-2008 23:59:30 
org.apache.tuscany.sca.host.embedded.impl.ReallySmallRuntim

e buildComposite
WARNING: Can't find monitor extension on the classpath
GService->initGService
Exception in thread "Thread-3" java.lang.IllegalArgumentException: 
Invalid phase

 name: component.implementation
at 
org.apache.tuscany.sca.core.invocation.InvocationChainImpl.addInvoker

(InvocationChainImpl.java:106)
at 
org.apache.tuscany.sca.core.invocation.InvocationChainImpl.addInvoker

(InvocationChainImpl.java:70)
at 
org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.addImplementatio

nInterceptor(RuntimeWireImpl.java:316)
at 
org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.initInvocationCh

ains(RuntimeWireImpl.java:188)
at 
org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.getInvocationCha

ins(RuntimeWireImpl.java:109)
at 
org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.getInvocationCha

in(RuntimeWireImpl.java:115)
at 
org.apache.tuscany.sca.core.assembly.RuntimeComponentServiceImpl.getI

nvocationChain(RuntimeComponentServiceImpl.java:120)
at 
org.apache.tuscany.sca.binding.sca.impl.RuntimeSCAReferenceBindingPro

vider.getInvoker(RuntimeSCAReferenceBindingProvider.java:232)
at 
org.apache.tuscany.sca.binding.sca.impl.RuntimeSCAReferenceBindingPro

vider.createInvoker(RuntimeSCAReferenceBindingProvider.java:245)
at 
org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.addReferenceBind

ingInterceptor(RuntimeWireImpl.java:228)
at 
org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.initInvocationCh

ains(RuntimeWireImpl.java:167)
at 
org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.getInvocationCha

ins(RuntimeWireImpl.java:109)
at 
org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.getInvoca

tionChain(JDKInvocationHandler.java:243)
at 
org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JD

KInvocationHandler.java:148)
at $Proxy17.setCurrentState(Unknown Source)
at 
org.apache.tuscany.sca.vtest.javaapi.annotations.scope.ScopeAnnotatio

nTestCase$CThread.run(ScopeAnnotationTestCase.java:311)
Exception in thread "Thread-4" org.osoa.sca.ServiceUnavailableException: 
Service
 not found for component CComponent reference $self$.CService 
(bindingURI=/CComp
onent operation=getName). Ensure that the composite containing the 
service is lo
aded and started somewhere in the SCA domain and that if running in a 
remote nod

e that the interface of the target service marked as @Remotable
at 
org.apache.tuscany.sca.binding.sca.impl.RuntimeSCAReferenceBindingPro

vider.createInvoker(RuntimeSCAReferenceBindingProvider.java:247)
at 
org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.addReferenceBind

ingInterceptor(RuntimeWireImpl.java:228)
at 
org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.initInvocationCh

ains(RuntimeWireImpl.java:167)
at 
org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.getInvocationCha

ins(RuntimeWireImpl.java:109)
at 
org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.getInvoca

tionChain(JDKInvocationHandler.java:243)
at 
org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JD

KInvocationHandler.java:148)
at $Proxy17.setCurrentState(Unknown Source)
at 
org.apache.tuscany.sca.vtest.javaapi.annotations.scope.ScopeAnnotatio

nTestCase$CThread.run(ScopeAnnotationTestCase.java:311)
ThreadB1->BService2
ThreadB2->BService9
atScope1 - Cleaning up
GService->destroyGService
atScope2 - Setting up
22-Apr-2008 23:59:31 
org.apache.tuscany.sca.host.embedded.impl.ReallySmallRuntim

e buildComposite
WARNING: Can't find monitor extension on the classpath
GService->initGService
DService1->initDService
ThreadD0->DService1
DService2->initDService
ThreadD1->DService2
DService3->initDService
ThreadD2->DService3
DService4->initDService
ThreadD3->DService4
DService5->initDService
ThreadD4->DService5
atScope2 - Cleaning up
GService->destroyGService

atScope3 - Setting up
22-Apr-2008 23:59:31 
org.apache.tuscany.sca.host.embedded.impl.ReallySmallRuntim

e buildComposite
WARNING: Can't find monitor extension on the classpath
GService->initGService
FService1->initFService
ThreadF0->FService1
ThreadF1->FService1
ThreadF2->FService1
ThreadF3->FService1
ThreadF4->FService1
atScope3 - Cleaning up
FService1->destroyFService
GService->destroyGService

atScope4 - Setting up
22-Apr-2008 23:59:31 
org.apache.tuscany.sca.host.embedded.impl.ReallySmallRuntim

e buildComposite
WARNING: Can't find monitor extension on the classpath
GService->initGService
atScope4 - Cleaning 

[jira] Resolved: (TUSCANY-2030) Java 2 security

[Raymond Feng (JIRA)]

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

Raymond Feng resolved TUSCANY-2030.
---

Resolution: Fixed

Patch applied under r650681. Thanks!

> Java 2 security
> ---
>
> Key: TUSCANY-2030
> URL: https://issues.apache.org/jira/browse/TUSCANY-2030
> Project: Tuscany
>  Issue Type: New Feature
>Affects Versions: Java-SCA-1.0.1
>Reporter: Greg Dritschler
>Assignee: Raymond Feng
> Fix For: Java-SCA-Next
>
> Attachments: TUSCANY-2030.patch
>
>
> In environments where Java 2 security is enabled, an AccessControlException 
> may occur in Tuscany code even though it has privileges to perform the 
> action, because there is code on the call stack that does not have such 
> privileges.  doPrivileged calls must be used around such actions.
> Here is an example of a failure.  There are undoubtedly others.
> java.security.AccessControlException: Access denied 
> (java.lang.RuntimePermission getClassLoader)
>   at 
> java.security.AccessController.checkPermission(AccessController.java:104)
>   at java.lang.SecurityManager.checkPermission(SecurityManager.java:547)
>   at 
> com.ibm.ws.security.core.SecurityManager.checkPermission(SecurityManager.java:189)
>   at java.lang.Class.getClassLoader(Class.java:234)
>   at 
> org.apache.tuscany.sca.core.invocation.JDKProxyFactory.createProxy(JDKProxyFactory.java:64)
>   at 
> org.apache.tuscany.sca.core.invocation.DefaultProxyFactoryExtensionPoint.createProxy(DefaultProxyFactoryExtensionPoint.java:105)
>   at 
> org.apache.tuscany.sca.core.context.CallableReferenceImpl.getInstance(CallableReferenceImpl.java:154)
>   at 
> org.apache.tuscany.sca.core.context.CallableReferenceImpl.getService(CallableReferenceImpl.java:162)
>   at 
> org.apache.tuscany.sca.host.embedded.impl.EmbeddedSCADomain.getService(EmbeddedSCADomain.java:138)
>   at 
> com.ibm.ws.soa.sca.runtime.impl.SimpleCompositeContextImpl.locateService(SimpleCompositeContextImpl.java:86)
>   at com.ibm._jsp._Calculator._jspService(_Calculator.java:96)

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

[jira] Resolved: (TUSCANY-2237) Java 2 Security - Enhancements to run Itest bucket

[Raymond Feng (JIRA)]

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

Raymond Feng resolved TUSCANY-2237.
---

Resolution: Fixed

Patch applied under 650681. Thanks

> Java 2 Security - Enhancements to run Itest bucket
> --
>
> Key: TUSCANY-2237
> URL: https://issues.apache.org/jira/browse/TUSCANY-2237
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Core Runtime
>Affects Versions: Java-SCA-1.1
> Environment: Java 1.5, Windows
>Reporter: Dan Becker
>Assignee: Raymond Feng
> Fix For: Java-SCA-Next
>
> Attachments: TUSCANY-2237-2.patch
>
>
> Must add proper Java 2 security to allow all Itests to run and pass JUnit 
> testing. An example of a failing Itest occurs with 
> CallableReferenceRemoteTestcase with Java 2 security enables. Here is an 
> example AccessControlException:
> java.security.AccessControlException: access denied 
> (java.util.PropertyPermission java.io.tmpdir read)
>   at java.security.AccessControlContext.checkPermission(Unknown Source)
>   at java.security.AccessController.checkPermission(Unknown Source)
>   at java.lang.SecurityManager.checkPermission(Unknown Source)
>   at java.lang.SecurityManager.checkPropertyAccess(Unknown Source)
>   at java.lang.System.getProperty(Unknown Source)
>   at 
> org.apache.axis2.context.ConfigurationContext.cleanupTemp(ConfigurationContext.java:665)
>   at 
> org.apache.axis2.context.ConfigurationContext.terminate(ConfigurationContext.java:653)
>   at 
> org.apache.axis2.transport.http.AxisServlet.destroy(AxisServlet.java:449)
>   at 
> org.apache.tuscany.sca.binding.ws.axis2.Axis2ServiceServlet.destroy(Axis2ServiceServlet.java:236)
>   at 
> org.apache.tuscany.sca.http.tomcat.ServletWrapper.destroyServlet(ServletWrapper.java:55)
>   at 
> org.apache.tuscany.sca.http.tomcat.TomcatServer.removeServletMapping(TomcatServer.java:510)
>   at 
> org.apache.tuscany.sca.binding.ws.axis2.Axis2ServiceProvider.stop(Axis2ServiceProvider.java:308)
>   at 
> org.apache.tuscany.sca.binding.ws.axis2.Axis2ServiceBindingProvider.stop(Axis2ServiceBindingProvider.java:98)
>   at 
> org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.stop(CompositeActivatorImpl.java:615)
>   at 
> org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.stop(CompositeActivatorImpl.java:513)
>   at 
> org.apache.tuscany.sca.node.impl.SCADomainProxyImpl.destroy(SCADomainProxyImpl.java:500)
>   at 
> org.apache.tuscany.sca.node.impl.SCANodeImpl.destroy(SCANodeImpl.java:441)
>   at 
> org.apache.tuscany.sca.itest.callableref.CallableReferenceRemoteTestCase.destroy(CallableReferenceRemoteTestCase.java:97)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
>   at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
>   at java.lang.reflect.Method.invoke(Unknown Source)
>   at 
> org.junit.internal.runners.BeforeAndAfterRunner.invokeMethod(BeforeAndAfterRunner.java:74)
>   at 
> org.junit.internal.runners.BeforeAndAfterRunner.runAfters(BeforeAndAfterRunner.java:65)
>   at 
> org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:37)
>   at 
> org.junit.internal.runners.TestClassRunner.run(TestClassRunner.java:52)
>   at 
> org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:38)
>   at 
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>   at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
>   at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
>   at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
>   at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
> This is fixed by adding AccessController.doPrivileged blocks around the 
> sensitive call

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

[jira] Closed: (TUSCANY-2257) Update and add tests to @Scope vtest

[Kevin Williams (JIRA)]

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

Kevin Williams closed TUSCANY-2257.
---

Resolution: Fixed

> Update and add tests to @Scope vtest
> 
>
> Key: TUSCANY-2257
> URL: https://issues.apache.org/jira/browse/TUSCANY-2257
> Project: Tuscany
>  Issue Type: Test
>  Components: Java SCA Verification Tests
>Affects Versions: Java-SCA-Next
>Reporter: Gilbert Kwan
>Assignee: Kevin Williams
>Priority: Minor
> Attachments: T2257-vtest.new.zip, T2257.vtest.patch
>
>


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

[jira] Created: (TUSCANY-2258) Spring Implementation support of Services isn't compliant with the Specification

[Kapish Aggarwal (JIRA)]

Spring Implementation support of Services isn't compliant with the Specification


 Key: TUSCANY-2258
 URL: https://issues.apache.org/jira/browse/TUSCANY-2258
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Spring Implementation Extension
 Environment: Not Specific, but current environment is Windows
Reporter: Kapish Aggarwal


Based on the specification (verbatim from PDF below):

Each  element used with  should include the 
name of the Spring bean
that is to be exposed as an SCA service in its name attribute. So, for Spring, 
the name attribute of a
service plays two roles: it identifies a Spring bean, and it names the service 
for the component. The service
element above has a name of "X", so there should be a Spring bean with that 
name.

This means in a component using implementation.spring, the "name" attribute of 
the service should be based on the value of the "id" attribute of the 
corresponding bean in the Spring context file. However, since Spring 
Implementation code piggybacks on the Java Introspection, it should the Java 
interface name instead. The SpringBeanIntrospector class's introspectBean 
method simply uses the Java implementation introspection and just copies the 
Services, References, and Properties directly over to the componentType object 
for the Spring Implementation. There needs to be some processing to ensure that 
the service is named based on the bean. I am unsure if the references and 
properties need have some extra processing involved either.

Example below:

Spring Context:



Component Element from Composite Should Be (This does not work):







Component  Element from Composite Actually Is (This works):







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

Re: [BRAINSTORM] Flexibility in distributed operation and extension implementations - was: Re: Request to propogate the value of a references target= attribute on its associated bindings model object

[Jean-Sebastien Delfino]

Simon Laws wrote:

On Mon, Apr 21, 2008 at 4:49 PM, Simon Laws <[EMAIL PROTECTED]>
wrote:



On Tue, Apr 15, 2008 at 6:10 PM, Yang Lei <[EMAIL PROTECTED]> wrote:


I agree with Simon's emphases on the point of view. I understand
Tuscany may prefer one solution over the other. However from
extensibility perspective, there need some extension points to enable
Tuscany adapters to overwrite the default behavior. I think the thread
discussion on reference target and the comparing of 1 and 2 showcase
one of the extensibility area :  how to resolve reference target for
different bindings.

I am actually looking beyond just reference target, I see the
extensibility in the following areas:

1. When/How to enable a binding to resolve the target endpoint . This
include the case to support reference target, and beyond, such as
supporting wireByImpl or autoWire. This also include distributed
support in case adapters have different ways to support distributed
contributions for a given virtual domain.

I understand Tuscany has workspace discussions. It may potentially be
a solution.I am still waiting to see how workspace is intending to
support distributed scenarios or how it can enable late binding on
resolving target endpoint. Regardless workspace is the solution or
not, we need the flexibility and extensibility to overwrite Tuscany's
default behavior on binding end point resolving.

2. When/How the binding resolvable is in used,

Some part of the Tuscany code is using binding resolved or not to have
different process  (see point 3). I think if certain logic outside
binding needs to understand if a binding is resolvable, we should make
it clear which method achieve it so binding implementations know what
to expect.

I can see Tuscany code uses binding's URI and targetComponentService
today, I think it should be limited to one method only, I am not sure
overloading URI is  good .

3. When/How to make binding selections on the reference side.

I can see Tuscany is trying to remove the unresolvable bindings first
from the reference side , then use some algorithm to either pick the
default binding if it exists or pick the first on the list.

I think we need some plug in point in Tuscany to enable different
algorithm from the above default behavior. And the plugin point need
to enable late binding so during reference's execution time we can
determine a binding is resolvable or not and then use some own
prioritizing rules to select the right bindings.


I would like to see these discussions concluded with a set of API and
some form of API interaction diagrams in the end.

Thanks.

Yang



I can see a couple of scenarios:



I thinkand binding selection that we need to enable some extension
points for others using other algorism or other

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



I've been thinking about this issue for a few days on and off and it seems
to me that the key to this is in the way that we store bindings that have
been read in from a composite file.

The assembly model starts out with each reference holding all the bindings
it is configured with in the composite file.

During model build the set of bindings is matched with targets and the
resulting list represents the set of resolved bindings complete with URIs
identifying target services. These bindings represent the runtime
configuration and are used to generate wires.

To do late binding we have to maintain the original set of bindings as
well as any bindings that have been fully resolved. In this way the
reference can resolve targets at runtime with all the information that is
used to resolve them at build time.

During the first domain implementation I ran across this problem and
stored the original list of bindings on the dummy target service that is
created for each target. However this is less than satisfactory as this list
is not persisted by the processors should the composite be written out
again.

If we reorganize the bindings such that we have a notion of candidate
bindings and resolved bindings then candidate bindings can be used at a
later point to create resolved bindings.

Much of the builder processing can be done early to associate policy with
bindings etc. But the wiring processing needs a bit of thinking about.
Anyhow this is not a fully formed thought but I'm throwing this out there as
I want to spend some time on this over the next few days and welcome any
input.

Regards

Simon



I've given this some more thought. It's a long post, sorry about that, but
just diving in and changing code is going to complicate matters on this one.


Requirements


A - late target service location
B - late binding selection
C - late autowire

A and B could be achieved at the time when a proxy is first called on the
understanding that an empty proxy can be first generated to represent these
unresolved wires.This is different 

[jira] Assigned: (TUSCANY-2257) Update and add tests to @Scope vtest

[Kevin Williams (JIRA)]

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

Kevin Williams reassigned TUSCANY-2257:
---

Assignee: Kevin Williams

> Update and add tests to @Scope vtest
> 
>
> Key: TUSCANY-2257
> URL: https://issues.apache.org/jira/browse/TUSCANY-2257
> Project: Tuscany
>  Issue Type: Test
>  Components: Java SCA Verification Tests
>Affects Versions: Java-SCA-Next
>Reporter: Gilbert Kwan
>Assignee: Kevin Williams
>Priority: Minor
> Attachments: T2257-vtest.new.zip, T2257.vtest.patch
>
>


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

[jira] Assigned: (TUSCANY-2030) Java 2 security

[Raymond Feng (JIRA)]

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

Raymond Feng reassigned TUSCANY-2030:
-

Assignee: Raymond Feng

> Java 2 security
> ---
>
> Key: TUSCANY-2030
> URL: https://issues.apache.org/jira/browse/TUSCANY-2030
> Project: Tuscany
>  Issue Type: New Feature
>Affects Versions: Java-SCA-1.0.1
>Reporter: Greg Dritschler
>Assignee: Raymond Feng
> Fix For: Java-SCA-Next
>
> Attachments: TUSCANY-2030.patch
>
>
> In environments where Java 2 security is enabled, an AccessControlException 
> may occur in Tuscany code even though it has privileges to perform the 
> action, because there is code on the call stack that does not have such 
> privileges.  doPrivileged calls must be used around such actions.
> Here is an example of a failure.  There are undoubtedly others.
> java.security.AccessControlException: Access denied 
> (java.lang.RuntimePermission getClassLoader)
>   at 
> java.security.AccessController.checkPermission(AccessController.java:104)
>   at java.lang.SecurityManager.checkPermission(SecurityManager.java:547)
>   at 
> com.ibm.ws.security.core.SecurityManager.checkPermission(SecurityManager.java:189)
>   at java.lang.Class.getClassLoader(Class.java:234)
>   at 
> org.apache.tuscany.sca.core.invocation.JDKProxyFactory.createProxy(JDKProxyFactory.java:64)
>   at 
> org.apache.tuscany.sca.core.invocation.DefaultProxyFactoryExtensionPoint.createProxy(DefaultProxyFactoryExtensionPoint.java:105)
>   at 
> org.apache.tuscany.sca.core.context.CallableReferenceImpl.getInstance(CallableReferenceImpl.java:154)
>   at 
> org.apache.tuscany.sca.core.context.CallableReferenceImpl.getService(CallableReferenceImpl.java:162)
>   at 
> org.apache.tuscany.sca.host.embedded.impl.EmbeddedSCADomain.getService(EmbeddedSCADomain.java:138)
>   at 
> com.ibm.ws.soa.sca.runtime.impl.SimpleCompositeContextImpl.locateService(SimpleCompositeContextImpl.java:86)
>   at com.ibm._jsp._Calculator._jspService(_Calculator.java:96)

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

[jira] Closed: (TUSCANY-2249) Updates to ComponentContext's vtest

[Kevin Williams (JIRA)]

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

Kevin Williams closed TUSCANY-2249.
---

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

> Updates to ComponentContext's vtest
> ---
>
> Key: TUSCANY-2249
> URL: https://issues.apache.org/jira/browse/TUSCANY-2249
> Project: Tuscany
>  Issue Type: Test
>  Components: Java SCA Verification Tests
>Reporter: Yee-Kang Chang
> Fix For: Java-SCA-Next
>
> Attachments: ComponentContextUpdatesJIRA2249.patch
>
>
> More vtest test cases for ComponentContext API.

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

[jira] Commented: (TUSCANY-2251) Problem with 1.2 RC4 with simple JavaBean

[Simon Nash (JIRA)]

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

Simon Nash commented on TUSCANY-2251:
-

Please can you give more details about how you are creating the Web Service 
client in Eclipse.

1. In Eclipse, are you generating the SimpleServicePortTypeProxy class from 
SampleServiceComponent.wsdl ("top down"), or are you generating it from 
SimpleService.java and SimpleBean.java ("bottom up")?

2. What level of Eclipse WTP and the JST/WST Web service tools are you using?  
What level of Axis2 does this pull in?

3. Please attach the generated client code that you are using in Eclipse 
(SimpleServicePortTypeProxy java and any other generated files).

Thanks!

> Problem with 1.2 RC4 with simple JavaBean
> -
>
> Key: TUSCANY-2251
> URL: https://issues.apache.org/jira/browse/TUSCANY-2251
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Data Binding Runtime
>Affects Versions: Java-SCA-1.2
> Environment: Eclipse 3.3, Tuscany SCA 1.2 - RC4
>Reporter: Nishant Joshi
> Fix For: Java-SCA-1.2
>
> Attachments: SimpleBeanProblem.zip
>
>
> Hi there,
> I have one sample which was perfectly working with 1.0 incubating... when i 
> have tried same with 1.2 RC4 all the data come from client was null for all 
> the values for a simple bean.
> Please note that I m creating Client on Eclipse 3.3... using WebService 
> client generation facility of eclipse...
> I m attaching detail for more detail...
> When tried same with SCA client it was giving me perfect result... 

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

[jira] Updated: (TUSCANY-2257) Update and add tests to @Scope vtest

[Gilbert Kwan (JIRA)]

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

Gilbert Kwan updated TUSCANY-2257:
--

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

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

> Update and add tests to @Scope vtest
> 
>
> Key: TUSCANY-2257
> URL: https://issues.apache.org/jira/browse/TUSCANY-2257
> Project: Tuscany
>  Issue Type: Test
>  Components: Java SCA Verification Tests
>Affects Versions: Java-SCA-Next
>Reporter: Gilbert Kwan
>Priority: Minor
> Attachments: T2257-vtest.new.zip, T2257.vtest.patch
>
>


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

[jira] Updated: (TUSCANY-2030) Java 2 security

[Dan Becker (JIRA)]

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

Dan Becker updated TUSCANY-2030:


Patch Info: [Patch Available]

> Java 2 security
> ---
>
> Key: TUSCANY-2030
> URL: https://issues.apache.org/jira/browse/TUSCANY-2030
> Project: Tuscany
>  Issue Type: New Feature
>Affects Versions: Java-SCA-1.0.1
>Reporter: Greg Dritschler
> Fix For: Java-SCA-Next
>
> Attachments: TUSCANY-2030.patch
>
>
> In environments where Java 2 security is enabled, an AccessControlException 
> may occur in Tuscany code even though it has privileges to perform the 
> action, because there is code on the call stack that does not have such 
> privileges.  doPrivileged calls must be used around such actions.
> Here is an example of a failure.  There are undoubtedly others.
> java.security.AccessControlException: Access denied 
> (java.lang.RuntimePermission getClassLoader)
>   at 
> java.security.AccessController.checkPermission(AccessController.java:104)
>   at java.lang.SecurityManager.checkPermission(SecurityManager.java:547)
>   at 
> com.ibm.ws.security.core.SecurityManager.checkPermission(SecurityManager.java:189)
>   at java.lang.Class.getClassLoader(Class.java:234)
>   at 
> org.apache.tuscany.sca.core.invocation.JDKProxyFactory.createProxy(JDKProxyFactory.java:64)
>   at 
> org.apache.tuscany.sca.core.invocation.DefaultProxyFactoryExtensionPoint.createProxy(DefaultProxyFactoryExtensionPoint.java:105)
>   at 
> org.apache.tuscany.sca.core.context.CallableReferenceImpl.getInstance(CallableReferenceImpl.java:154)
>   at 
> org.apache.tuscany.sca.core.context.CallableReferenceImpl.getService(CallableReferenceImpl.java:162)
>   at 
> org.apache.tuscany.sca.host.embedded.impl.EmbeddedSCADomain.getService(EmbeddedSCADomain.java:138)
>   at 
> com.ibm.ws.soa.sca.runtime.impl.SimpleCompositeContextImpl.locateService(SimpleCompositeContextImpl.java:86)
>   at com.ibm._jsp._Calculator._jspService(_Calculator.java:96)

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

[jira] Updated: (TUSCANY-2030) Java 2 security

[Dan Becker (JIRA)]

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

Dan Becker updated TUSCANY-2030:


Attachment: TUSCANY-2030.patch

This patch when used in conjunction with fixes for TUSCANY-2108 and 
TUSCANY-2237 allow the Tuscany runtime to run under WAS 7.0 plus SOA FeP with 
Java 2 security on. However, there are still some security errors in the 
WebSphere code, which prevents the calculator sample from running error free.

> Java 2 security
> ---
>
> Key: TUSCANY-2030
> URL: https://issues.apache.org/jira/browse/TUSCANY-2030
> Project: Tuscany
>  Issue Type: New Feature
>Affects Versions: Java-SCA-1.0.1
>Reporter: Greg Dritschler
> Fix For: Java-SCA-Next
>
> Attachments: TUSCANY-2030.patch
>
>
> In environments where Java 2 security is enabled, an AccessControlException 
> may occur in Tuscany code even though it has privileges to perform the 
> action, because there is code on the call stack that does not have such 
> privileges.  doPrivileged calls must be used around such actions.
> Here is an example of a failure.  There are undoubtedly others.
> java.security.AccessControlException: Access denied 
> (java.lang.RuntimePermission getClassLoader)
>   at 
> java.security.AccessController.checkPermission(AccessController.java:104)
>   at java.lang.SecurityManager.checkPermission(SecurityManager.java:547)
>   at 
> com.ibm.ws.security.core.SecurityManager.checkPermission(SecurityManager.java:189)
>   at java.lang.Class.getClassLoader(Class.java:234)
>   at 
> org.apache.tuscany.sca.core.invocation.JDKProxyFactory.createProxy(JDKProxyFactory.java:64)
>   at 
> org.apache.tuscany.sca.core.invocation.DefaultProxyFactoryExtensionPoint.createProxy(DefaultProxyFactoryExtensionPoint.java:105)
>   at 
> org.apache.tuscany.sca.core.context.CallableReferenceImpl.getInstance(CallableReferenceImpl.java:154)
>   at 
> org.apache.tuscany.sca.core.context.CallableReferenceImpl.getService(CallableReferenceImpl.java:162)
>   at 
> org.apache.tuscany.sca.host.embedded.impl.EmbeddedSCADomain.getService(EmbeddedSCADomain.java:138)
>   at 
> com.ibm.ws.soa.sca.runtime.impl.SimpleCompositeContextImpl.locateService(SimpleCompositeContextImpl.java:86)
>   at com.ibm._jsp._Calculator._jspService(_Calculator.java:96)

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

[jira] Created: (TUSCANY-2257) Update and add tests to @Scope vtest

[Gilbert Kwan (JIRA)]

Update and add tests to @Scope vtest


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




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

[jira] Updated: (TUSCANY-2256) Request scope service works as composite scope service

[Gilbert Kwan (JIRA)]

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

Gilbert Kwan updated TUSCANY-2256:
--

Description: 
There are 3 components
 - JComponent (composite scope)
 - KComponent (stateless scope)
 - LComponent  (request scope)

When the composite runs, composite scope service JComponent kicks off a timer 
by the @Init method.  The timer triggers JComponent every second to invoke a 
method that calls an operation on the reference to a stateless scope sevice 
KComponent. KComponent calls a request scope service LComponent multiple times.

We found that there was only one instance of LComponent be used and the state 
was also preserved. Although it was declared as a request scope service, it 
worked like as a composite scope service. (See the attached powerpoint.)

The "SCA Java Annotations And APIs V1" specification line 292 to 293.says, "... 
the lifetime of the request is implementation dependent.".


  was:
There are 3 components
 - JComponent (composite scope)
 - KComponent (stateless scope)
 - LComponent  (request scope)

When the composite runs, composite scope service JComponent kicks off a timer 
by the @Init method.  The timer triggers JComponent every second to invoke a 
method that calls an operation on the reference to a stateless scope sevice 
KComponent. KComponent calls a request scope service LComponent multiple times.

We found that there was only one instance of LComponent be used and the state 
was also preserved. Although it was declared as a request
scope service, it worked like as a composite scope service. (See the attached 
powerpoint.)

The "SCA Java Annotations And APIs V1" specification line 292 to 293.says, "... 
the lifetime of the request is implementation
dependent.".



> Request scope service works as composite scope service
> --
>
> Key: TUSCANY-2256
> URL: https://issues.apache.org/jira/browse/TUSCANY-2256
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Core Runtime
>Affects Versions: Java-SCA-Next
>Reporter: Gilbert Kwan
> Attachments: RequestWorkAsComposite.ppt
>
>
> There are 3 components
>  - JComponent (composite scope)
>  - KComponent (stateless scope)
>  - LComponent  (request scope)
> When the composite runs, composite scope service JComponent kicks off a timer 
> by the @Init method.  The timer triggers JComponent every second to invoke a 
> method that calls an operation on the reference to a stateless scope sevice 
> KComponent. KComponent calls a request scope service LComponent multiple 
> times.
> We found that there was only one instance of LComponent be used and the state 
> was also preserved. Although it was declared as a request scope service, it 
> worked like as a composite scope service. (See the attached powerpoint.)
> The "SCA Java Annotations And APIs V1" specification line 292 to 293.says, 
> "... the lifetime of the request is implementation dependent.".

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

[jira] Updated: (TUSCANY-2256) Request scope service works as composite scope service

[Gilbert Kwan (JIRA)]

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

Gilbert Kwan updated TUSCANY-2256:
--

Attachment: RequestWorkAsComposite.ppt

Diagram to show the problem

> Request scope service works as composite scope service
> --
>
> Key: TUSCANY-2256
> URL: https://issues.apache.org/jira/browse/TUSCANY-2256
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Core Runtime
>Affects Versions: Java-SCA-Next
>Reporter: Gilbert Kwan
> Attachments: RequestWorkAsComposite.ppt
>
>
> There are 3 components
>  - JComponent (composite scope)
>  - KComponent (stateless scope)
>  - LComponent  (request scope)
> When the composite runs, composite scope service JComponent kicks off a timer 
> by the @Init method.  The timer triggers JComponent every second to invoke a 
> method that calls an operation on the reference to a stateless scope sevice 
> KComponent. KComponent calls a request scope service LComponent multiple 
> times.
> We found that there was only one instance of LComponent be used and the state 
> was also preserved. Although it was declared as a request
> scope service, it worked like as a composite scope service. (See the attached 
> powerpoint.)
> The "SCA Java Annotations And APIs V1" specification line 292 to 293.says, 
> "... the lifetime of the request is implementation
> dependent.".

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

[jira] Created: (TUSCANY-2256) Request scope service works as composite scope service

[Gilbert Kwan (JIRA)]

Request scope service works as composite scope service
--

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


There are 3 components
 - JComponent (composite scope)
 - KComponent (stateless scope)
 - LComponent  (request scope)

When the composite runs, composite scope service JComponent kicks off a timer 
by the @Init method.  The timer triggers JComponent every second to invoke a 
method that calls an operation on the reference to a stateless scope sevice 
KComponent. KComponent calls a request scope service LComponent multiple times.

We found that there was only one instance of LComponent be used and the state 
was also preserved. Although it was declared as a request
scope service, it worked like as a composite scope service. (See the attached 
powerpoint.)

The "SCA Java Annotations And APIs V1" specification line 292 to 293.says, "... 
the lifetime of the request is implementation
dependent.".


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

Re: [BRAINSTORM] Flexibility in distributed operation and extension implementations - was: Re: Request to propogate the value of a references target= attribute on its associated bindings model object

[Simon Laws]

On Mon, Apr 21, 2008 at 4:49 PM, Simon Laws <[EMAIL PROTECTED]>
wrote:

>
>
> On Tue, Apr 15, 2008 at 6:10 PM, Yang Lei <[EMAIL PROTECTED]> wrote:
>
> > I agree with Simon's emphases on the point of view. I understand
> > Tuscany may prefer one solution over the other. However from
> > extensibility perspective, there need some extension points to enable
> > Tuscany adapters to overwrite the default behavior. I think the thread
> > discussion on reference target and the comparing of 1 and 2 showcase
> > one of the extensibility area :  how to resolve reference target for
> > different bindings.
> >
> > I am actually looking beyond just reference target, I see the
> > extensibility in the following areas:
> >
> > 1. When/How to enable a binding to resolve the target endpoint . This
> > include the case to support reference target, and beyond, such as
> > supporting wireByImpl or autoWire. This also include distributed
> > support in case adapters have different ways to support distributed
> > contributions for a given virtual domain.
> >
> > I understand Tuscany has workspace discussions. It may potentially be
> > a solution.I am still waiting to see how workspace is intending to
> > support distributed scenarios or how it can enable late binding on
> > resolving target endpoint. Regardless workspace is the solution or
> > not, we need the flexibility and extensibility to overwrite Tuscany's
> > default behavior on binding end point resolving.
> >
> > 2. When/How the binding resolvable is in used,
> >
> > Some part of the Tuscany code is using binding resolved or not to have
> > different process  (see point 3). I think if certain logic outside
> > binding needs to understand if a binding is resolvable, we should make
> > it clear which method achieve it so binding implementations know what
> > to expect.
> >
> > I can see Tuscany code uses binding's URI and targetComponentService
> > today, I think it should be limited to one method only, I am not sure
> > overloading URI is  good .
> >
> > 3. When/How to make binding selections on the reference side.
> >
> > I can see Tuscany is trying to remove the unresolvable bindings first
> > from the reference side , then use some algorithm to either pick the
> > default binding if it exists or pick the first on the list.
> >
> > I think we need some plug in point in Tuscany to enable different
> > algorithm from the above default behavior. And the plugin point need
> > to enable late binding so during reference's execution time we can
> > determine a binding is resolvable or not and then use some own
> > prioritizing rules to select the right bindings.
> >
> >
> > I would like to see these discussions concluded with a set of API and
> > some form of API interaction diagrams in the end.
> >
> > Thanks.
> >
> > Yang
> >
> >
> >
> > I can see a couple of scenarios:
> >
> >
> >
> > I thinkand binding selection that we need to enable some extension
> > points for others using other algorism or other
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> I've been thinking about this issue for a few days on and off and it seems
> to me that the key to this is in the way that we store bindings that have
> been read in from a composite file.
>
> The assembly model starts out with each reference holding all the bindings
> it is configured with in the composite file.
>
> During model build the set of bindings is matched with targets and the
> resulting list represents the set of resolved bindings complete with URIs
> identifying target services. These bindings represent the runtime
> configuration and are used to generate wires.
>
> To do late binding we have to maintain the original set of bindings as
> well as any bindings that have been fully resolved. In this way the
> reference can resolve targets at runtime with all the information that is
> used to resolve them at build time.
>
> During the first domain implementation I ran across this problem and
> stored the original list of bindings on the dummy target service that is
> created for each target. However this is less than satisfactory as this list
> is not persisted by the processors should the composite be written out
> again.
>
> If we reorganize the bindings such that we have a notion of candidate
> bindings and resolved bindings then candidate bindings can be used at a
> later point to create resolved bindings.
>
> Much of the builder processing can be done early to associate policy with
> bindings etc. But the wiring processing needs a bit of thinking about.
> Anyhow this is not a fully formed thought but I'm throwing this out there as
> I want to spend some time on this over the next few days and welcome any
> input.
>
> Regards
>
> Simon
>

I've given this some more thought. It's a long post, sorry about that, but
just diving in and changing code is going to complicate matters o

[jira] Commented: (TUSCANY-1997) Axis binding does not allow external configuration to increase the number of the maximum connections opened.

[Catalin Boloaja (JIRA)]

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

Catalin Boloaja commented on TUSCANY-1997:
--

Hi Ant ,

Thank you for your new jar.
I have tried the patch and unfortunately  I can not say it's working.
In the server side I can see only two threads being used and after using a tool 
to generate the load in the client side , the response time report shows 
continuous growth in the response time .
Can you confirm this approach is working ?

I have also a question related to the use of a ThreadPool in the client side , 
why was this needed for ?

Thank you ,

Catalin Boloaja 

> Axis binding does not allow external configuration to increase the number of 
> the maximum connections opened.
> 
>
> Key: TUSCANY-1997
> URL: https://issues.apache.org/jira/browse/TUSCANY-1997
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Axis Binding Extension
>Affects Versions: Java-SCA-Next
> Environment: Solaris , Windows , Websphere , Tomcat
>Reporter: Catalin Boloaja
>Assignee: Jean-Sebastien Delfino
> Fix For: Java-SCA-Next
>
> Attachments: 
> tuscany-binding-ws-axis2-1.0-incubating-TUSCANY-1997.jar, 
> tuscany-binding-ws-axis2-1.0-T1997-T1893.jar, 
> tuscany-binding-ws-axis2-1.1-TUSCANY-1997.jar
>
>
> In a high volume situation the default setting for Axis2 is 2 connections per 
> host.
> The default protocol being HTTP 1.1 , this means that only 2 POST requests 
> can be issued at the same time.

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

Re: [GSoC] Accepted Student Proposals for 2008 Announced

[Oscar Castaneda]

Dear all,
I was very excited to see the results yesterday! I would like to thank the
Apache Tuscany community, especially the mentors for GSoc. Their help was
vital in creating my proposal.

I will work hard to complete this project successfully. I'm looking forward
to this great opportunity!

best,
-oscar

2008/4/22 Luciano Resende <[EMAIL PROTECTED]>:

> It's now official, Google has announced the accepted student proposals
> for 2008 [1] and the ASF accepted proposals is also available [2].It's
> very good to see that all the effort done by the Tuscany Community has
> now materialized as 6 excellent proposals accepted.
>
> I'd also want to take this opportunity to welcome the new students to
> the community, and of course, thanks for all the Tuscany Community
> that steeped up as mentors and are going to be helping these students
> trough out  the summer and hopefully for a much bigger period of time.
>
> See below the Apache Tuscany approved student proposals
>
> Tuscany SCA Support in the Geronimo Admin Console
> by Thilina Mahesh Buddhika, mentored by Ant Elder
>
> Simplify the development of Map/Reduce applications and their
> integration with various sources of information
> by Christopher Trezzo, mentored by Jean-Sebastien Delfino
>
> Allow Google Android applications to easily consume business services
> (version 2.0 - 6Apr2008 @17.50)
> by Oscar Castaneda, mentored by Adriano Crestani Campos
>
> Integrate Google Services in SCA Compositions
> by Douglas Siqueira Leite, mentored by Luciano Resende
>
> CORBA support for Apache Tuscany
> by Wojtek, mentored by Zhaohui Feng
>
> Integrate Google services in SCA compositions（Apache Tuscany）
> by Haibo Zhao, mentored by Luciano Resende
>
> [1] http://code.google.com/soc/2008/
> [2] http://code.google.com/soc/2008/asf/about.html
>
> --
> Luciano Resende
> Apache Tuscany Committer
> http://people.apache.org/~lresende
> http://lresende.blogspot.com/
>

Re: Request scope service works as composite scope service

[Raymond Feng]

Hi,

By looking into the code, I assume this is a missing piece in Tuscany to 
track/control the lifecycle of the request scope. Ideally, when a new 
request comes into SCA, we create a request scope container and all of the 
request-scoped component instances will be associated with the scope 
container. Once the request is finished, all the component instances in the 
scope container will be notified to perform the @Destroy actions. Please 
open a JIRA.


Thanks,
Raymond

--
From: "Gilbert Kwan" <[EMAIL PROTECTED]>
Sent: Tuesday, April 22, 2008 8:52 AM
To: 
Subject: Request scope service works as composite scope service


We created a test to test the "SCA Java Annotations And APIs V1"
specification lines 290 to 293.

"There are times when a local request scoped service is called without
there being a remotable service earlier in the call stack, such as
when a local service is called from a non-SCA entity. In these cases,
a remote request is always considered to be present, but the lifetime
of the request is implementation dependent. For example, a timer event
could be treated as a remote request."

There are 3 components
- JComponent (composite scope)
- KComponent (stateless scope)
- LComponent  (request scope)

When the composite runs, composite scope service JComponent kicks off
a timer by the @Init method.  The timer triggers JComponent every
second to invoke a method that calls an operation on the reference to
a stateless scope sevice KComponent. KComponent calls a request scope
service LComponent multiple times.

We found that there was only one instance of LComponent be used and
the state was also preserved. Although it was declared as a request
scope service, it worked like as a composite scope service. (See the
attached powerpoint.)

As the spec says, "... the lifetime of the request is implementation
dependent.". Is there a bug?

Thanks
Gilbert

Re: Adding SVN version to Java files

[Raymond Feng]

I guess you missed my +1. :-)

Raymond

--
From: "Mark Combellack" <[EMAIL PROTECTED]>
Sent: Tuesday, April 22, 2008 6:15 AM
To: 
Subject: RE: Adding SVN version to Java files


-Original Message-
From: Jean-Sebastien Delfino [mailto:[EMAIL PROTECTED]
Sent: 15 April 2008 02:59
To: tuscany-dev@ws.apache.org
Subject: Re: Adding SVN version to Java files

Mark Combellack wrote:
> Hi,
>
> I've been looking through the Tuscany source code and noticed that some
> files have a @version containing the SVN revision number in their
JavaDoc
> headers but others do not.
>
> As an example, @version might look like:
>
> /**
>  * Some JavaDoc for the class
>  *
>  * @version $Rev: 598005 $ $Date: 2007-11-25 16:36:27 + (Sun, 25 
> Nov

> 2007) $
>  */
>
> I would like to go through the Tuscany source code and add this header
where
> it is missing. This would involve a large number of minor changes to 
> the
> Tuscany tree so I wanted to run it by everyone to make sure no-one had 
> a

> problem with me doing this at this time.
>
> I'll probably start this next week unless there is an objection.
>
> Thanks,
>
> Mark
>
>

I'm replying again to the original message in this thread, as there
doesn't seem to be any conclusion yet. Does anybody understand where we
are with this?

I'm usually adding the SVN rev tag to the files I touch when I see that
it's missing. I guess I can continue like that but it doesn't sound
ideal, so I'm still +1 on Mark's proposal.

Anyway, Mark Thanks for volunteering to do this. I was hoping it'd take
less than 3 weeks to reach consensus on changes like that which don't
break anything...
--
Jean-Sebastien

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



This topic appears to have gone quiet. I guess this means that we have a
"consensus" since there appears to be no active debate on this subject.

In summary of this thread, we have:

   +1 from Mark, Vasmi, Luciano and Sebastian.

   ant prefers not to do this

   Simon says he would find it useful.


From the above, we have 4 +1s and no -1s - although we have a preference 
not

to do this from ant. So, the consensus is to make this change.

I'll hold off making the changes for a few days and then start later this
week.

Thanks,

Mark

Request scope service works as composite scope service

[Gilbert Kwan]

We created a test to test the "SCA Java Annotations And APIs V1"
specification lines 290 to 293.

"There are times when a local request scoped service is called without
there being a remotable service earlier in the call stack, such as
when a local service is called from a non-SCA entity. In these cases,
a remote request is always considered to be present, but the lifetime
of the request is implementation dependent. For example, a timer event
could be treated as a remote request."

There are 3 components
 - JComponent (composite scope)
 - KComponent (stateless scope)
 - LComponent  (request scope)

When the composite runs, composite scope service JComponent kicks off
a timer by the @Init method.  The timer triggers JComponent every
second to invoke a method that calls an operation on the reference to
a stateless scope sevice KComponent. KComponent calls a request scope
service LComponent multiple times.

We found that there was only one instance of LComponent be used and
the state was also preserved. Although it was declared as a request
scope service, it worked like as a composite scope service. (See the
attached powerpoint.)

As the spec says, "... the lifetime of the request is implementation
dependent.". Is there a bug?

Thanks
Gilbert


RequestWorkAsComposite.ppt
Description: MS-Powerpoint presentation

[jira] Resolved: (TUSCANY-2113) Problem with fault comparison in DataTransformationInterceptor; maybe we should compare elem QNames, not type QNames?

[Raymond Feng (JIRA)]

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

Raymond Feng resolved TUSCANY-2113.
---

Resolution: Fixed

Fixed under r650561

> Problem with fault comparison in DataTransformationInterceptor; maybe we 
> should compare elem QNames, not type QNames?
> -
>
> Key: TUSCANY-2113
> URL: https://issues.apache.org/jira/browse/TUSCANY-2113
> Project: Tuscany
>  Issue Type: Bug
>Affects Versions: Java-SCA-1.1
>Reporter: Scott Kurz
>Assignee: Raymond Feng
> Fix For: Java-SCA-Next
>
>
> There's a problem with how the fault matching in DTI uses the private 
> DTI.typesMatch() method.
> I don't think it should be allowing a matching type name to return 'true', 
> i.e. indicate a successful match.
>return matches(t1.getElementName(), t2.getElementName()) || 
> matches(t1.getTypeName(), t2.getTypeName());
> For one, I could have two distinct fault elems of the same type. 
> In addition, also note that, if you have a fault element with anonymous type, 
> the generated JAXB will look like:
> @XmlType(name = ""..)
> so we will build up an XMLType with typeName equal to a namespace plus a null 
> name.One problem with this is that there is no way to distinguish between 
> two fault elems in the same NS, with anonymous types. 
> I haven't given this a huge amount of thought so I mention this in case 
> anyone thinks of other issues relating to some of the points I am making.

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

[jira] Commented: (TUSCANY-2243) ServiceRuntimeException due to NPE with ComponentContext.getService()

[Yee-Kang Chang (JIRA)]

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

Yee-Kang Chang commented on TUSCANY-2243:
-

Changes in the attached patch has been applied to the trunk via JIRA 2249.  
Thanks.

> ServiceRuntimeException due to NPE with ComponentContext.getService()
> -
>
> Key: TUSCANY-2243
> URL: https://issues.apache.org/jira/browse/TUSCANY-2243
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Core Runtime
>Reporter: Yee-Kang Chang
> Attachments: ComponentContextUpdatesJIRA2243.patch
>
>
> ComponentContext.getService() did not return the expected service when 
> invoked.  It works with a @Reference field is defined for the service in the 
> Impl class but it failed without the annotation.  The reference is defined in 
> the SCDL.
> Section 1.4.1.1 of the specification says, "When a component implementation 
> needs access to a service where the reference to the service is not known at 
> compile time, the reference can be located using the component's 
> ComponentContext."  So, this should work without @Reference defined.
> org.osoa.sca.ServiceRuntimeException: java.lang.NullPointerException
>   at 
> org.apache.tuscany.sca.core.context.ComponentContextImpl.getServiceReference(ComponentContextImpl.java:228)
>   at 
> org.apache.tuscany.sca.core.context.ComponentContextImpl.getServiceReference(ComponentContextImpl.java:110)
>   at 
> org.apache.tuscany.sca.core.context.ComponentContextImpl.getService(ComponentContextImpl.java:102)
>   at 
> org.apache.tuscany.sca.vtest.javaapi.apis.componentcontext.impl.AComponentImpl.testServiceLookup(AComponentImpl.java:96)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:79)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:618)
>   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 $Proxy7.testServiceLookup(Unknown Source)
>   at 
> org.apache.tuscany.sca.vtest.javaapi.apis.componentcontext.ComponentContextTestCase.testServiceLookup(ComponentContextTestCase.java:170)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:79)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:618)
>   at 
> org.junit.internal.runners.TestMethodRunner.executeMethodBody(TestMethodRunner.java:99)
>   at 
> org.junit.internal.runners.TestMethodRunner.runUnprotected(TestMethodRunner.java:81)
>   at 
> org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34)
>   at 
> org.junit.internal.runners.TestMethodRunner.runMethod(TestMethodRunner.java:75)
>   at 
> org.junit.internal.runners.TestMethodRunner.run(TestMethodRunner.java:45)
>   at 
> org.junit.internal.runners.TestClassMethodsRunner.invokeTestMethod(TestClassMethodsRunner.java:75)
>   at 
> org.junit.internal.runners.TestClassMethodsRunner.run(TestClassMethodsRunner.java:36)
>   at 
> org.junit.internal.runners.TestClassRunner$1.runUnprotected(TestClassRunner.java:42)
>   at 
> org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34)
>   at 
> org.junit.internal.runners.TestClassRunner.run(TestClassRunner.java:52)
>   at 
> org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:38)
>   at 
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>   at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
>   at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
>   at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
>   at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
> Caused by: java.lang.NullPointerException
>   at 
> org.apache.tuscany.sca.core.context.ComponentContextImpl.getInterfaceContract(ComponentContextImpl.java:34

[jira] Commented: (TUSCANY-2249) Updates to ComponentContext's vtest

[Yee-Kang Chang (JIRA)]

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

Yee-Kang Chang commented on TUSCANY-2249:
-

Thanks, Ant!  The failed test case has to do with the problem I reported in 
JIRA 2250.  Thank you.

> Updates to ComponentContext's vtest
> ---
>
> Key: TUSCANY-2249
> URL: https://issues.apache.org/jira/browse/TUSCANY-2249
> Project: Tuscany
>  Issue Type: Test
>  Components: Java SCA Verification Tests
>Reporter: Yee-Kang Chang
> Attachments: ComponentContextUpdatesJIRA2249.patch
>
>
> More vtest test cases for ComponentContext API.

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

RE: Adding SVN version to Java files

[Mark Combellack]

> -Original Message-
> From: Jean-Sebastien Delfino [mailto:[EMAIL PROTECTED]
> Sent: 15 April 2008 02:59
> To: tuscany-dev@ws.apache.org
> Subject: Re: Adding SVN version to Java files
> 
> Mark Combellack wrote:
> > Hi,
> >
> > I've been looking through the Tuscany source code and noticed that some
> > files have a @version containing the SVN revision number in their
> JavaDoc
> > headers but others do not.
> >
> > As an example, @version might look like:
> >
> > /**
> >  * Some JavaDoc for the class
> >  *
> >  * @version $Rev: 598005 $ $Date: 2007-11-25 16:36:27 + (Sun, 25 Nov
> > 2007) $
> >  */
> >
> > I would like to go through the Tuscany source code and add this header
> where
> > it is missing. This would involve a large number of minor changes to the
> > Tuscany tree so I wanted to run it by everyone to make sure no-one had a
> > problem with me doing this at this time.
> >
> > I'll probably start this next week unless there is an objection.
> >
> > Thanks,
> >
> > Mark
> >
> >
> 
> I'm replying again to the original message in this thread, as there
> doesn't seem to be any conclusion yet. Does anybody understand where we
> are with this?
> 
> I'm usually adding the SVN rev tag to the files I touch when I see that
> it's missing. I guess I can continue like that but it doesn't sound
> ideal, so I'm still +1 on Mark's proposal.
> 
> Anyway, Mark Thanks for volunteering to do this. I was hoping it'd take
> less than 3 weeks to reach consensus on changes like that which don't
> break anything...
> --
> Jean-Sebastien
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]


This topic appears to have gone quiet. I guess this means that we have a
"consensus" since there appears to be no active debate on this subject.

In summary of this thread, we have:

+1 from Mark, Vasmi, Luciano and Sebastian.

ant prefers not to do this

Simon says he would find it useful.


>From the above, we have 4 +1s and no -1s - although we have a preference not
to do this from ant. So, the consensus is to make this change.

I'll hold off making the changes for a few days and then start later this
week.

Thanks,

Mark

[jira] Closed: (TUSCANY-2241) EndpointReference in binding.ws when wsdlElement is not of 'Binding' form

[ant elder (JIRA)]

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

ant elder closed TUSCANY-2241.
--

Resolution: Fixed

Applied in r650504

> EndpointReference in binding.ws when wsdlElement is not of 'Binding' form
> -
>
> Key: TUSCANY-2241
> URL: https://issues.apache.org/jira/browse/TUSCANY-2241
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Verification Tests
>Affects Versions: Java-SCA-1.2, Java-SCA-Next
>Reporter: Vamsavardhana Reddy
>Assignee: Vamsavardhana Reddy
> Fix For: Java-SCA-Next
>
> Attachments: TUSCANY-2241-test.patch, TUSCANY-2241.patch
>
>
> Web Service Binding Specification v1.0 - Sec 2.1 - Lines 61 to 65:
> 61 • /binding.ws/wsa:EndpointReference - optional WS-Addressing [6] 
> EndpointReference
> 62 that specifies the endpoint for the service or reference. When this 
> element is present along
> 63 with the wsdlElement attribute on the parent element, the wsdlElement 
> attribute value MUST
> 64 be of the 'Binding' form as specified above, i.e.  65 URI>#wsdl.binding().
> I notice that when an EndpointReference is specified inside binding.ws along 
> with a wsdlElement which is not of 'Binding' form, no warning or error is 
> generated.

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

Re: How do you plug in validation monitoring?

[Simon Laws]

On Tue, Apr 22, 2008 at 1:16 PM, Hasan Muhammad <[EMAIL PROTECTED]> wrote:

> Hi Simon
>
> I opened JIRA 2255 and attached a patch for the new testcases.
>
> Hasan
>
> On Fri, Apr 18, 2008 at 12:58 PM, Simon Laws <[EMAIL PROTECTED]>
> wrote:
>
> > On Thu, Apr 17, 2008 at 5:44 PM, Simon Laws <[EMAIL PROTECTED]>
> > wrote:
> >
> > >
> > >
> > > On Thu, Apr 17, 2008 at 5:02 PM, Hasan Muhammad <[EMAIL PROTECTED]>
> > wrote:
> > >
> > > > Hi Simon,
> > > >
> > > > We should have an api for plugins to provide a resource bundle. This
> > api
> > > > probably needs to be on the monitor or somewhere, i am not sure. But
> > the
> > > > scenario occurs when plugins want to use the default Monitor but
> still
> > > > want
> > > > to use their own resource bundle for messageIDs.
> > > >
> > > > regards
> > > > Hasan
> > > >
> > > > On Wed, Apr 16, 2008 at 3:30 PM, Hasan Muhammad <[EMAIL PROTECTED]>
> > > > wrote:
> > > >
> > > > > Hi Simon,
> > > > >
> > > > > I looked at the new Monitor and Problem interfaces. What do
> > > > getMessageId()
> > > > > and getMessageParams() actually return? is MessageId a way to
> > > > categorize the
> > > > > error message?
> > > > >
> > > > > regards
> > > > > Hasan
> > > > >
> > > > >
> > > > > On Tue, Apr 15, 2008 at 10:59 AM, Hasan Muhammad <[EMAIL PROTECTED]
> >
> > > > wrote:
> > > > >
> > > > > > Hi Simon,
> > > > > >
> > > > > > I was wondering if i can cook up some validation test cases if
> > they
> > > > do
> > > > > > not exist. Or should we wait until the monitor issue is resolved
> ?
> > > > > >
> > > > > > Hasan
> > > > > >
> > > > > >
> > > > > > On Thu, Apr 10, 2008 at 4:34 PM, Hasan Muhammad <
> [EMAIL PROTECTED]>
> > > > > > wrote:
> > > > > >
> > > > > > > Hi Simon,
> > > > > > >
> > > > > > > I dont think using an underlying tuscany jdk logger would be
> > > > useful to
> > > > > > > plugins as they may not want to log, rather show it somewhere
> > else
> > > > such as
> > > > > > > console etc. Tuscany can use an underlying logger in it's own
> > > > monitor ( as
> > > > > > > it uses today). But i think the first approach of using a
> > monitor
> > > > is better
> > > > > > > along with the condition that it be made more usable by the
> > > > plugins by
> > > > > > > giving them greater control.
> > > > > > >
> > > > > > > Another point is that tuscany should use ResourceBundle for
> > > > validation
> > > > > > > messages as well. I dont think this is being done today.
> > > > > > >
> > > > > > > regards
> > > > > > > Hasan
> > > > > > >
> > > > > > >
> > > > > > > On Wed, Apr 9, 2008 at 1:22 PM, Simon Laws <
> > > > [EMAIL PROTECTED]>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > On Wed, Apr 9, 2008 at 12:49 PM, Simon Laws <
> > > > > > > > [EMAIL PROTECTED]>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Wed, Apr 9, 2008 at 12:00 PM, Hasan Muhammad <
> > > > [EMAIL PROTECTED]>
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > Hi Simon,
> > > > > > > > > >
> > > > > > > > > > I am on revision 634808. The ContributionServiceImpl has
> > > > changed
> > > > > > > > since
> > > > > > > > > > then,
> > > > > > > > > > and with the one that i have, it would lead through the
> > > > > > > > > > CompositeProcessor
> > > > > > > > > > instead of the CompositeDocumentProcessor. Hence the
> > > > difference
> > > > > > > > in
> > > > > > > > > > exceptions..
> > > > > > > > > >
> > > > > > > > > > Also, dont you think that with the error that you got
> > should
> > > > > > > > throw an
> > > > > > > > > > exception with schema validation, rather than just a
> > > > warning?
> > > > > > > > > >
> > > > > > > > > > Hasan
> > > > > > > > > >
> > > > > > > > > > On Wed, Apr 9, 2008 at 6:36 AM, Simon Laws <
> > > > > > > > [EMAIL PROTECTED]>
> > > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > On Tue, Apr 8, 2008 at 2:58 PM, Hasan Muhammad <
> > > > > > > > [EMAIL PROTECTED]>
> > > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > > Hi Simon,
> > > > > > > > > > > >
> > > > > > > > > > > > Thank you for the good information. First up i am
> > trying
> > > > to
> > > > > > > > verify
> > > > > > > > > > > whether
> > > > > > > > > > > > the schema validation works when we point to our
> > > > schemas.
> > > > > > > > Can you
> > > > > > > > > > let me
> > > > > > > > > > > > know what is a simple error that i can introduce so
> > that
> > > > i
> > > > > > > > can
> > > > > > > > > > verify
> > > > > > > > > > > > this?
> > > > > > > > > > > > I tried doing this to my composite file (In block
> > red):
> > > > > > > > > > > >
> > > > > > > > > > > >  
> > > > > > > > > > > > > > > > > > > > > > class="mysca.test.myservice.impl.MyServiceImpl"/>
> > > > > > > > > > > >**
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >  
> > > > > > > > > > > >
> > > > > > > > > > > > This resulted in the following exception, but i
> think
> > > > this
> > > > 

[jira] Resolved: (TUSCANY-2255) Validation Testcases Part -1

[Simon Laws (JIRA)]

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

Simon Laws resolved TUSCANY-2255.
-

Resolution: Fixed

Thanks Hasan. I've commited the patch at r650505. I made a few changes to 
remove the unused code that got copied over from the original test. But apart 
from that looks good. 

> Validation Testcases Part -1
> 
>
> Key: TUSCANY-2255
> URL: https://issues.apache.org/jira/browse/TUSCANY-2255
> Project: Tuscany
>  Issue Type: Test
>  Components: Java SCA Integration Tests
> Environment: All
>Reporter: Hasan Muhammad
>Assignee: Simon Laws
>Priority: Minor
> Attachments: validation1.patch
>
>
> Hi Simon,
> Submitting the first round of validation Itest cases. Please review and 
> commit if the patch is ok. Otherwise let me know and i will just create a 
> patch for the diff files and create a zip for the new files.
> Hasan

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

[jira] Assigned: (TUSCANY-2255) Validation Testcases Part -1

[Simon Laws (JIRA)]

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

Simon Laws reassigned TUSCANY-2255:
---

Assignee: Simon Laws

> Validation Testcases Part -1
> 
>
> Key: TUSCANY-2255
> URL: https://issues.apache.org/jira/browse/TUSCANY-2255
> Project: Tuscany
>  Issue Type: Test
>  Components: Java SCA Integration Tests
> Environment: All
>Reporter: Hasan Muhammad
>Assignee: Simon Laws
>Priority: Minor
> Attachments: validation1.patch
>
>
> Hi Simon,
> Submitting the first round of validation Itest cases. Please review and 
> commit if the patch is ok. Otherwise let me know and i will just create a 
> patch for the diff files and create a zip for the new files.
> Hasan

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

Re: How do you plug in validation monitoring?

[Hasan Muhammad]

Hi Simon

I opened JIRA 2255 and attached a patch for the new testcases.

Hasan

On Fri, Apr 18, 2008 at 12:58 PM, Simon Laws <[EMAIL PROTECTED]>
wrote:

> On Thu, Apr 17, 2008 at 5:44 PM, Simon Laws <[EMAIL PROTECTED]>
> wrote:
>
> >
> >
> > On Thu, Apr 17, 2008 at 5:02 PM, Hasan Muhammad <[EMAIL PROTECTED]>
> wrote:
> >
> > > Hi Simon,
> > >
> > > We should have an api for plugins to provide a resource bundle. This
> api
> > > probably needs to be on the monitor or somewhere, i am not sure. But
> the
> > > scenario occurs when plugins want to use the default Monitor but still
> > > want
> > > to use their own resource bundle for messageIDs.
> > >
> > > regards
> > > Hasan
> > >
> > > On Wed, Apr 16, 2008 at 3:30 PM, Hasan Muhammad <[EMAIL PROTECTED]>
> > > wrote:
> > >
> > > > Hi Simon,
> > > >
> > > > I looked at the new Monitor and Problem interfaces. What do
> > > getMessageId()
> > > > and getMessageParams() actually return? is MessageId a way to
> > > categorize the
> > > > error message?
> > > >
> > > > regards
> > > > Hasan
> > > >
> > > >
> > > > On Tue, Apr 15, 2008 at 10:59 AM, Hasan Muhammad <[EMAIL PROTECTED]>
> > > wrote:
> > > >
> > > > > Hi Simon,
> > > > >
> > > > > I was wondering if i can cook up some validation test cases if
> they
> > > do
> > > > > not exist. Or should we wait until the monitor issue is resolved ?
> > > > >
> > > > > Hasan
> > > > >
> > > > >
> > > > > On Thu, Apr 10, 2008 at 4:34 PM, Hasan Muhammad <[EMAIL PROTECTED]>
> > > > > wrote:
> > > > >
> > > > > > Hi Simon,
> > > > > >
> > > > > > I dont think using an underlying tuscany jdk logger would be
> > > useful to
> > > > > > plugins as they may not want to log, rather show it somewhere
> else
> > > such as
> > > > > > console etc. Tuscany can use an underlying logger in it's own
> > > monitor ( as
> > > > > > it uses today). But i think the first approach of using a
> monitor
> > > is better
> > > > > > along with the condition that it be made more usable by the
> > > plugins by
> > > > > > giving them greater control.
> > > > > >
> > > > > > Another point is that tuscany should use ResourceBundle for
> > > validation
> > > > > > messages as well. I dont think this is being done today.
> > > > > >
> > > > > > regards
> > > > > > Hasan
> > > > > >
> > > > > >
> > > > > > On Wed, Apr 9, 2008 at 1:22 PM, Simon Laws <
> > > [EMAIL PROTECTED]>
> > > > > > wrote:
> > > > > >
> > > > > > > On Wed, Apr 9, 2008 at 12:49 PM, Simon Laws <
> > > > > > > [EMAIL PROTECTED]>
> > > > > > > wrote:
> > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > On Wed, Apr 9, 2008 at 12:00 PM, Hasan Muhammad <
> > > [EMAIL PROTECTED]>
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Hi Simon,
> > > > > > > > >
> > > > > > > > > I am on revision 634808. The ContributionServiceImpl has
> > > changed
> > > > > > > since
> > > > > > > > > then,
> > > > > > > > > and with the one that i have, it would lead through the
> > > > > > > > > CompositeProcessor
> > > > > > > > > instead of the CompositeDocumentProcessor. Hence the
> > > difference
> > > > > > > in
> > > > > > > > > exceptions..
> > > > > > > > >
> > > > > > > > > Also, dont you think that with the error that you got
> should
> > > > > > > throw an
> > > > > > > > > exception with schema validation, rather than just a
> > > warning?
> > > > > > > > >
> > > > > > > > > Hasan
> > > > > > > > >
> > > > > > > > > On Wed, Apr 9, 2008 at 6:36 AM, Simon Laws <
> > > > > > > [EMAIL PROTECTED]>
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > On Tue, Apr 8, 2008 at 2:58 PM, Hasan Muhammad <
> > > > > > > [EMAIL PROTECTED]>
> > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > Hi Simon,
> > > > > > > > > > >
> > > > > > > > > > > Thank you for the good information. First up i am
> trying
> > > to
> > > > > > > verify
> > > > > > > > > > whether
> > > > > > > > > > > the schema validation works when we point to our
> > > schemas.
> > > > > > > Can you
> > > > > > > > > let me
> > > > > > > > > > > know what is a simple error that i can introduce so
> that
> > > i
> > > > > > > can
> > > > > > > > > verify
> > > > > > > > > > > this?
> > > > > > > > > > > I tried doing this to my composite file (In block
> red):
> > > > > > > > > > >
> > > > > > > > > > >  
> > > > > > > > > > > > > > > > > > > > class="mysca.test.myservice.impl.MyServiceImpl"/>
> > > > > > > > > > >**
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >  
> > > > > > > > > > >
> > > > > > > > > > > This resulted in the following exception, but i think
> > > this
> > > > > > > is part
> > > > > > > > > of
> > > > > > > > > > the
> > > > > > > > > > > validation done by artifact processor and would result
> > > even
> > > > > > > if we
> > > > > > > > > > comment
> > > > > > > > > > > out the schema validation.
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > org.apache.tuscany.sca.contribution.service.ContributionReadException:
> >

[jira] Created: (TUSCANY-2255) Validation Testcases Part -1

[Hasan Muhammad (JIRA)]

Validation Testcases Part -1


 Key: TUSCANY-2255
 URL: https://issues.apache.org/jira/browse/TUSCANY-2255
 Project: Tuscany
  Issue Type: Test
  Components: Java SCA Integration Tests
 Environment: All
Reporter: Hasan Muhammad
Priority: Minor
 Attachments: validation1.patch

Hi Simon,

Submitting the first round of validation Itest cases. Please review and commit 
if the patch is ok. Otherwise let me know and i will just create a patch for 
the diff files and create a zip for the new files.

Hasan

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

[jira] Updated: (TUSCANY-2255) Validation Testcases Part -1

[Hasan Muhammad (JIRA)]

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

Hasan Muhammad updated TUSCANY-2255:


Attachment: validation1.patch

> Validation Testcases Part -1
> 
>
> Key: TUSCANY-2255
> URL: https://issues.apache.org/jira/browse/TUSCANY-2255
> Project: Tuscany
>  Issue Type: Test
>  Components: Java SCA Integration Tests
> Environment: All
>Reporter: Hasan Muhammad
>Priority: Minor
> Attachments: validation1.patch
>
>
> Hi Simon,
> Submitting the first round of validation Itest cases. Please review and 
> commit if the patch is ok. Otherwise let me know and i will just create a 
> patch for the diff files and create a zip for the new files.
> Hasan

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

[jira] Commented: (TUSCANY-2253) TuscanyServletFilter cannot be initialized when no display-name is specified in web.xml

[wangfeng (JIRA)]

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

wangfeng commented on TUSCANY-2253:
---

In version 1.1,tuscany will use the display name to generate the domain uri.So 
if you use 1.1 and the display name is not be set ,it will throw an null 
pointer exception.

But in version 1.2,the generating algorithm have been modified and the display 
name has not be used any more.

What version are you using? can you try the latest version that can be 
downloaded from [1].

[1] http://people.apache.org/~lresende/tuscany/sca-1.2-RC4/

> TuscanyServletFilter cannot be initialized when no display-name is specified 
> in web.xml
> ---
>
> Key: TUSCANY-2253
> URL: https://issues.apache.org/jira/browse/TUSCANY-2253
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Web App Integration
>Affects Versions: Java-SCA-1.1
>Reporter: Ilya Kanonirov
>
> When the display-name element is not specified in web.xml, 
> TuscanyServletFilter fails to initialize with the following exception:
> 16:27:52,393 ERROR [[/]] Exception starting filter tuscany
> java.lang.NullPointerException
> at 
> org.apache.tuscany.sca.host.webapp.WebAppServletHost.init(WebAppServletHost.java:209)
> at 
> org.apache.tuscany.sca.host.webapp.TuscanyServletFilter.init(TuscanyServletFilter.java:51)
> at 
> org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:225)
> at 
> org.apache.catalina.core.ApplicationFilterConfig.setFilterDef(ApplicationFilterConfig.java:308)
> at 
> org.apache.catalina.core.ApplicationFilterConfig.(ApplicationFilterConfig.java:79)
> at 
> org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:3540)
> at 
> org.apache.catalina.core.StandardContext.start(StandardContext.java:4110)
> at 
> org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:759)
> at 
> org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:739)
> at 
> org.apache.catalina.core.StandardHost.addChild(StandardHost.java:524)
> 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)
> ...

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

[jira] Updated: (TUSCANY-2241) EndpointReference in binding.ws when wsdlElement is not of 'Binding' form

[Vamsavardhana Reddy (JIRA)]

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

Vamsavardhana Reddy updated TUSCANY-2241:
-

Attachment: TUSCANY-2241-test.patch

TUSCANY-2241-test.patch:  Testcase to make sure an exception is thrown on a bad 
wsdlElement..

> EndpointReference in binding.ws when wsdlElement is not of 'Binding' form
> -
>
> Key: TUSCANY-2241
> URL: https://issues.apache.org/jira/browse/TUSCANY-2241
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Verification Tests
>Affects Versions: Java-SCA-1.2, Java-SCA-Next
>Reporter: Vamsavardhana Reddy
>Assignee: Vamsavardhana Reddy
> Fix For: Java-SCA-Next
>
> Attachments: TUSCANY-2241-test.patch, TUSCANY-2241.patch
>
>
> Web Service Binding Specification v1.0 - Sec 2.1 - Lines 61 to 65:
> 61 • /binding.ws/wsa:EndpointReference - optional WS-Addressing [6] 
> EndpointReference
> 62 that specifies the endpoint for the service or reference. When this 
> element is present along
> 63 with the wsdlElement attribute on the parent element, the wsdlElement 
> attribute value MUST
> 64 be of the 'Binding' form as specified above, i.e.  65 URI>#wsdl.binding().
> I notice that when an EndpointReference is specified inside binding.ws along 
> with a wsdlElement which is not of 'Binding' form, no warning or error is 
> generated.

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

[jira] Reopened: (TUSCANY-2241) EndpointReference in binding.ws when wsdlElement is not of 'Binding' form

[Vamsavardhana Reddy (JIRA)]

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

Vamsavardhana Reddy reopened TUSCANY-2241:
--


Test is due :(

> EndpointReference in binding.ws when wsdlElement is not of 'Binding' form
> -
>
> Key: TUSCANY-2241
> URL: https://issues.apache.org/jira/browse/TUSCANY-2241
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Verification Tests
>Affects Versions: Java-SCA-1.2, Java-SCA-Next
>Reporter: Vamsavardhana Reddy
>Assignee: Vamsavardhana Reddy
> Fix For: Java-SCA-Next
>
> Attachments: TUSCANY-2241.patch
>
>
> Web Service Binding Specification v1.0 - Sec 2.1 - Lines 61 to 65:
> 61 • /binding.ws/wsa:EndpointReference - optional WS-Addressing [6] 
> EndpointReference
> 62 that specifies the endpoint for the service or reference. When this 
> element is present along
> 63 with the wsdlElement attribute on the parent element, the wsdlElement 
> attribute value MUST
> 64 be of the 'Binding' form as specified above, i.e.  65 URI>#wsdl.binding().
> I notice that when an EndpointReference is specified inside binding.ws along 
> with a wsdlElement which is not of 'Binding' form, no warning or error is 
> generated.

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

[jira] Updated: (TUSCANY-2252) Remove exception declaration from SCANodeManagerService Interface

[Ramkumar Ramalingam (JIRA)]

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

Ramkumar Ramalingam updated TUSCANY-2252:
-

Attachment: TUSCANY-2252.patch

> Remove exception declaration from SCANodeManagerService Interface
> -
>
> Key: TUSCANY-2252
> URL: https://issues.apache.org/jira/browse/TUSCANY-2252
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Domain Management
>Affects Versions: Java-SCA-Next
>Reporter: Ramkumar Ramalingam
>Assignee: Ramkumar Ramalingam
> Fix For: Java-SCA-Next
>
> Attachments: TUSCANY-2252.patch
>
>
> org.apache.tuscany.sca.node.NodeException: 
> org.apache.tuscany.sca.interfacedef.InvalidOperationException: Method should 
> not declare exceptions with an @OneWay annotation.
> at 
> org.apache.tuscany.sca.node.impl.SCANodeImpl.init(SCANodeImpl.java:222)
> at 
> org.apache.tuscany.sca.node.impl.SCANodeImpl.(SCANodeImpl.java:128)
> at 
> org.apache.tuscany.sca.node.impl.SCANodeFactoryImpl.createSCANode(SCANodeFactoryImpl.java:54)
> at 
> org.apache.tuscany.sca.node.impl.NodeDrivenTestCase.init(NodeDrivenTestCase.java:72)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:615)
> at 
> org.junit.internal.runners.BeforeAndAfterRunner.invokeMethod(BeforeAndAfterRunner.java:74)
> at 
> org.junit.internal.runners.BeforeAndAfterRunner.runBefores(BeforeAndAfterRunner.java:50)
> at 
> org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:33)
> at 
> org.junit.internal.runners.TestClassRunner.run(TestClassRunner.java:52)
> 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:64)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:615)
> at 
> org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:308)
> at 
> org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:879)
>  
> DomainDrivenTestCase fails with the above exception as we have a 
> destroyNode() method in 
> org.apache.tuscany.sca.node.management.SCANodeManagerService.java interface 
> with @OneWay annotation, but declared to throw NodeException.
>  
> As per the specs, "Any method that returns "void" and has no declared 
> exceptions may be marked with an @OneWay annotation."
>  
> I am raising this JIRA to fix this issue by making the destroyNode() method 
> not to throw any exception.

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

[jira] Resolved: (TUSCANY-2254) Test failures in itest/osgi-tuscany (monitor missing)

[Simon Laws (JIRA)]

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

Simon Laws resolved TUSCANY-2254.
-

Resolution: Fixed

Thanks Graham for the patch. Applied at r650438

> Test failures in itest/osgi-tuscany (monitor missing)
> -
>
> Key: TUSCANY-2254
> URL: https://issues.apache.org/jira/browse/TUSCANY-2254
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Core Runtime
>Affects Versions: Java-SCA-Next
> Environment: Found on Windows, but affects all.
>Reporter: Graham Charters
>Assignee: Simon Laws
>Priority: Minor
> Fix For: Java-SCA-Next
>
> Attachments: osgi-tuscany-patch.patch
>
>   Original Estimate: 0.5h
>  Remaining Estimate: 0.5h
>
> The newly added monitor modules, tuscany-monitor and tuscany-monitor-logging 
> ,cause itest/osgi-tuscany to fail because they have not been added to the 
> dependencies for the tuscany osgi bundles.

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

[jira] Assigned: (TUSCANY-2254) Test failures in itest/osgi-tuscany (monitor missing)

[Simon Laws (JIRA)]

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

Simon Laws reassigned TUSCANY-2254:
---

Assignee: Simon Laws

> Test failures in itest/osgi-tuscany (monitor missing)
> -
>
> Key: TUSCANY-2254
> URL: https://issues.apache.org/jira/browse/TUSCANY-2254
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Core Runtime
>Affects Versions: Java-SCA-Next
> Environment: Found on Windows, but affects all.
>Reporter: Graham Charters
>Assignee: Simon Laws
>Priority: Minor
> Fix For: Java-SCA-Next
>
> Attachments: osgi-tuscany-patch.patch
>
>   Original Estimate: 0.5h
>  Remaining Estimate: 0.5h
>
> The newly added monitor modules, tuscany-monitor and tuscany-monitor-logging 
> ,cause itest/osgi-tuscany to fail because they have not been added to the 
> dependencies for the tuscany osgi bundles.

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

[jira] Updated: (TUSCANY-2254) Test failures in itest/osgi-tuscany (monitor missing)

[Graham Charters (JIRA)]

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

Graham Charters updated TUSCANY-2254:
-

Attachment: osgi-tuscany-patch.patch

The following adds tuscany-monitor to the tuscany-runtime bundle and 
tuscany-monitor-logging to the tuscany-extensions bundle, built by 
itest/osgi-tuscany.

> Test failures in itest/osgi-tuscany (monitor missing)
> -
>
> Key: TUSCANY-2254
> URL: https://issues.apache.org/jira/browse/TUSCANY-2254
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Core Runtime
>Affects Versions: Java-SCA-Next
> Environment: Found on Windows, but affects all.
>Reporter: Graham Charters
>Priority: Minor
> Fix For: Java-SCA-Next
>
> Attachments: osgi-tuscany-patch.patch
>
>   Original Estimate: 0.5h
>  Remaining Estimate: 0.5h
>
> The newly added monitor modules, tuscany-monitor and tuscany-monitor-logging 
> ,cause itest/osgi-tuscany to fail because they have not been added to the 
> dependencies for the tuscany osgi bundles.

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

[jira] Created: (TUSCANY-2254) Test failures in itest/osgi-tuscany (monitor missing)

[Graham Charters (JIRA)]

Test failures in itest/osgi-tuscany (monitor missing)
-

 Key: TUSCANY-2254
 URL: https://issues.apache.org/jira/browse/TUSCANY-2254
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Core Runtime
Affects Versions: Java-SCA-Next
 Environment: Found on Windows, but affects all.
Reporter: Graham Charters
Priority: Minor
 Fix For: Java-SCA-Next


The newly added monitor modules, tuscany-monitor and tuscany-monitor-logging 
,cause itest/osgi-tuscany to fail because they have not been added to the 
dependencies for the tuscany osgi bundles.

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

[jira] Created: (TUSCANY-2253) TuscanyServletFilter cannot be initialized when no display-name is specified in web.xml

[Ilya Kanonirov (JIRA)]

TuscanyServletFilter cannot be initialized when no display-name is specified in 
web.xml
---

 Key: TUSCANY-2253
 URL: https://issues.apache.org/jira/browse/TUSCANY-2253
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Web App Integration
Affects Versions: Java-SCA-1.1
Reporter: Ilya Kanonirov


When the display-name element is not specified in web.xml, TuscanyServletFilter 
fails to initialize with the following exception:
16:27:52,393 ERROR [[/]] Exception starting filter tuscany
java.lang.NullPointerException
at 
org.apache.tuscany.sca.host.webapp.WebAppServletHost.init(WebAppServletHost.java:209)
at 
org.apache.tuscany.sca.host.webapp.TuscanyServletFilter.init(TuscanyServletFilter.java:51)
at 
org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:225)
at 
org.apache.catalina.core.ApplicationFilterConfig.setFilterDef(ApplicationFilterConfig.java:308)
at 
org.apache.catalina.core.ApplicationFilterConfig.(ApplicationFilterConfig.java:79)
at 
org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:3540)
at 
org.apache.catalina.core.StandardContext.start(StandardContext.java:4110)
at 
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:759)
at 
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:739)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:524)
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)
...

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

[jira] Commented: (TUSCANY-2252) Remove exception declaration from SCANodeManagerService Interface

[Ramkumar Ramalingam (JIRA)]

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

Ramkumar Ramalingam commented on TUSCANY-2252:
--

By removing the declared exception from destroyNode() method in 
org.apache.tuscany.sca.node.management.SCANodeManagerService.java interface 
with @OneWay annotation, we might also need to reflect the same change in 
org.apache.tuscany.sca.node.management.impl.SCANodeManagerServiceImpl.java

> Remove exception declaration from SCANodeManagerService Interface
> -
>
> Key: TUSCANY-2252
> URL: https://issues.apache.org/jira/browse/TUSCANY-2252
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Domain Management
>Affects Versions: Java-SCA-Next
>Reporter: Ramkumar Ramalingam
>Assignee: Ramkumar Ramalingam
> Fix For: Java-SCA-Next
>
>
> org.apache.tuscany.sca.node.NodeException: 
> org.apache.tuscany.sca.interfacedef.InvalidOperationException: Method should 
> not declare exceptions with an @OneWay annotation.
> at 
> org.apache.tuscany.sca.node.impl.SCANodeImpl.init(SCANodeImpl.java:222)
> at 
> org.apache.tuscany.sca.node.impl.SCANodeImpl.(SCANodeImpl.java:128)
> at 
> org.apache.tuscany.sca.node.impl.SCANodeFactoryImpl.createSCANode(SCANodeFactoryImpl.java:54)
> at 
> org.apache.tuscany.sca.node.impl.NodeDrivenTestCase.init(NodeDrivenTestCase.java:72)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:615)
> at 
> org.junit.internal.runners.BeforeAndAfterRunner.invokeMethod(BeforeAndAfterRunner.java:74)
> at 
> org.junit.internal.runners.BeforeAndAfterRunner.runBefores(BeforeAndAfterRunner.java:50)
> at 
> org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:33)
> at 
> org.junit.internal.runners.TestClassRunner.run(TestClassRunner.java:52)
> 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:64)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:615)
> at 
> org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:308)
> at 
> org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:879)
>  
> DomainDrivenTestCase fails with the above exception as we have a 
> destroyNode() method in 
> org.apache.tuscany.sca.node.management.SCANodeManagerService.java interface 
> with @OneWay annotation, but declared to throw NodeException.
>  
> As per the specs, "Any method that returns "void" and has no declared 
> exceptions may be marked with an @OneWay annotation."
>  
> I am raising this JIRA to fix this issue by making the destroyNode() method 
> not to throw any exception.

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

Re: svn-commit r650405 - org.apache.tuscany.sca.node.impl.DomainDrivenTestCase.java

[Ramkumar R]

On 4/22/08, Ramkumar R <[EMAIL PROTECTED]> wrote:
>
> org.apache.tuscany.sca.node.NodeException:
> org.apache.tuscany.sca.interfacedef.InvalidOperationException: Method should
> not declare exceptions with an @OneWay annotation.
> at
> org.apache.tuscany.sca.node.impl.SCANodeImpl.init(SCANodeImpl.java:222)
> at
> org.apache.tuscany.sca.node.impl.SCANodeImpl.(SCANodeImpl.java:128)
> at
> org.apache.tuscany.sca.node.impl.SCANodeFactoryImpl.createSCANode(SCANodeFactoryImpl.java:54)
> at
> org.apache.tuscany.sca.node.impl.NodeDrivenTestCase.init(NodeDrivenTestCase.java:72)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:615)
> at
> org.junit.internal.runners.BeforeAndAfterRunner.invokeMethod(BeforeAndAfterRunner.java:74)
> at
> org.junit.internal.runners.BeforeAndAfterRunner.runBefores(BeforeAndAfterRunner.java:50)
> at
> org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:33)
> at
> org.junit.internal.runners.TestClassRunner.run(TestClassRunner.java:52)
> 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:64)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:615)
> at
> org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:308)
> at
> org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:879)
>
> DomainDrivenTestCase fails with the above exception as we have a
> destroyNode() method in
> org.apache.tuscany.sca.node.management.SCANodeManagerService.java interface
> with @OneWay annotation, but declared to throw NodeException.
>
> As per the specs, "Any method that returns "void" and has no declared
> exceptions may be marked with an @OneWay annotation."
>
> I am raising a JIRA to fix this issue by making the destroyNode() method
> not to throw any exception.
>
> --
> Thanks & Regards,
> Ramkumar Ramalingam
>
I have raised TUSCANY-2252 to make the destroyNode() method not to throw any
exception. Please let me know if there could be any other issue by doing so.
Thanks.

-- 
Thanks & Regards,
Ramkumar Ramalingam

[jira] Created: (TUSCANY-2252) Remove exception declaration from SCANodeManagerService Interface

[Ramkumar Ramalingam (JIRA)]

Remove exception declaration from SCANodeManagerService Interface
-

 Key: TUSCANY-2252
 URL: https://issues.apache.org/jira/browse/TUSCANY-2252
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Domain Management
Affects Versions: Java-SCA-Next
Reporter: Ramkumar Ramalingam
Assignee: Ramkumar Ramalingam
 Fix For: Java-SCA-Next


org.apache.tuscany.sca.node.NodeException: 
org.apache.tuscany.sca.interfacedef.InvalidOperationException: Method should 
not declare exceptions with an @OneWay annotation.
at 
org.apache.tuscany.sca.node.impl.SCANodeImpl.init(SCANodeImpl.java:222)
at 
org.apache.tuscany.sca.node.impl.SCANodeImpl.(SCANodeImpl.java:128)
at 
org.apache.tuscany.sca.node.impl.SCANodeFactoryImpl.createSCANode(SCANodeFactoryImpl.java:54)
at 
org.apache.tuscany.sca.node.impl.NodeDrivenTestCase.init(NodeDrivenTestCase.java:72)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:615)
at 
org.junit.internal.runners.BeforeAndAfterRunner.invokeMethod(BeforeAndAfterRunner.java:74)
at 
org.junit.internal.runners.BeforeAndAfterRunner.runBefores(BeforeAndAfterRunner.java:50)
at 
org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:33)
at 
org.junit.internal.runners.TestClassRunner.run(TestClassRunner.java:52)
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:64)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:615)
at 
org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:308)
at 
org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:879)
 
DomainDrivenTestCase fails with the above exception as we have a destroyNode() 
method in org.apache.tuscany.sca.node.management.SCANodeManagerService.java 
interface with @OneWay annotation, but declared to throw NodeException.
 
As per the specs, "Any method that returns "void" and has no declared 
exceptions may be marked with an @OneWay annotation."
 
I am raising this JIRA to fix this issue by making the destroyNode() method not 
to throw any exception.

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

svn-commit r650405 - org.apache.tuscany.sca.node.impl.DomainDrivenTestCase.java

[Ramkumar R]

org.apache.tuscany.sca.node.NodeException:
org.apache.tuscany.sca.interfacedef.InvalidOperationException: Method should
not declare exceptions with an @OneWay annotation.
at
org.apache.tuscany.sca.node.impl.SCANodeImpl.init(SCANodeImpl.java:222)
at
org.apache.tuscany.sca.node.impl.SCANodeImpl.(SCANodeImpl.java:128)
at
org.apache.tuscany.sca.node.impl.SCANodeFactoryImpl.createSCANode(SCANodeFactoryImpl.java:54)
at
org.apache.tuscany.sca.node.impl.NodeDrivenTestCase.init(NodeDrivenTestCase.java:72)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:615)
at
org.junit.internal.runners.BeforeAndAfterRunner.invokeMethod(BeforeAndAfterRunner.java:74)
at
org.junit.internal.runners.BeforeAndAfterRunner.runBefores(BeforeAndAfterRunner.java:50)
at
org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:33)
at
org.junit.internal.runners.TestClassRunner.run(TestClassRunner.java:52)
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:64)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:615)
at
org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:308)
at
org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:879)

DomainDrivenTestCase fails with the above exception as we have a
destroyNode() method in
org.apache.tuscany.sca.node.management.SCANodeManagerService.java interface
with @OneWay annotation, but declared to throw NodeException.

As per the specs, "Any method that returns "void" and has no declared
exceptions may be marked with an @OneWay annotation."

I am raising a JIRA to fix this issue by making the destroyNode() method not
to throw any exception.

-- 
Thanks & Regards,
Ramkumar Ramalingam

[jira] Commented: (TUSCANY-2249) Updates to ComponentContext's vtest

[ant elder (JIRA)]

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

ant elder commented on TUSCANY-2249:


Applied in r650408. Note though that the testGetRequestContext method is 
failing for me so I've added @Ignore to that. Is there some associated change 
that needs to be made?

> Updates to ComponentContext's vtest
> ---
>
> Key: TUSCANY-2249
> URL: https://issues.apache.org/jira/browse/TUSCANY-2249
> Project: Tuscany
>  Issue Type: Test
>  Components: Java SCA Verification Tests
>Reporter: Yee-Kang Chang
> Attachments: ComponentContextUpdatesJIRA2249.patch
>
>
> More vtest test cases for ComponentContext API.

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

[jira] Closed: (TUSCANY-2241) EndpointReference in binding.ws when wsdlElement is not of 'Binding' form

[ant elder (JIRA)]

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

ant elder closed TUSCANY-2241.
--

Resolution: Fixed

Patch applied, thanks for the fix!

> EndpointReference in binding.ws when wsdlElement is not of 'Binding' form
> -
>
> Key: TUSCANY-2241
> URL: https://issues.apache.org/jira/browse/TUSCANY-2241
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Verification Tests
>Affects Versions: Java-SCA-1.2, Java-SCA-Next
>Reporter: Vamsavardhana Reddy
>Assignee: Vamsavardhana Reddy
> Fix For: Java-SCA-Next
>
> Attachments: TUSCANY-2241.patch
>
>
> Web Service Binding Specification v1.0 - Sec 2.1 - Lines 61 to 65:
> 61 • /binding.ws/wsa:EndpointReference - optional WS-Addressing [6] 
> EndpointReference
> 62 that specifies the endpoint for the service or reference. When this 
> element is present along
> 63 with the wsdlElement attribute on the parent element, the wsdlElement 
> attribute value MUST
> 64 be of the 'Binding' form as specified above, i.e.  65 URI>#wsdl.binding().
> I notice that when an EndpointReference is specified inside binding.ws along 
> with a wsdlElement which is not of 'Binding' form, no warning or error is 
> generated.

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

Re: Renaming SDO CTS

[Wang Feng]

+1
 
Thanks,
Wang Feng

On 2008-04-22 00:52:34,Luciano Resende <[EMAIL PROTECTED]> wrote:

>I'd like to rename the CTS svn project to SDO-CTS Please let me know
>if anyone have issues here, otherwise I want to do this on the next
>couple days.
>
>-- 
>Luciano Resende
>Apache Tuscany Committer
>http://people.apache.org/~lresende
>http://lresende.blogspot.com/
>
>-
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>

Re: Renaming SDO CTS

[Vamsavardhana Reddy]

+1

++Vamsi

On Mon, Apr 21, 2008 at 10:22 PM, Luciano Resende <[EMAIL PROTECTED]>
wrote:

> I'd like to rename the CTS svn project to SDO-CTS Please let me know
> if anyone have issues here, otherwise I want to do this on the next
> couple days.
>
> --
> Luciano Resende
> Apache Tuscany Committer
> http://people.apache.org/~lresende 
> http://lresende.blogspot.com/
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Re: Renaming SDO CTS

[Simon Laws]

On Mon, Apr 21, 2008 at 7:29 PM, Jean-Sebastien Delfino <
[EMAIL PROTECTED]> wrote:

> Luciano Resende wrote:
>
> > I'd like to rename the CTS svn project to SDO-CTS Please let me know
> > if anyone have issues here, otherwise I want to do this on the next
> > couple days.
> >
> >
> +1
>
> --
> Jean-Sebastien
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
> +1