[jira] Created: (TUSCANY-2040) BUILD FAILURE : Apache Tuscany SCA HelloWorld Web Service JMS Sample

[Venkatakrishnan (JIRA)]

BUILD FAILURE : Apache Tuscany SCA HelloWorld Web Service JMS Sample


 Key: TUSCANY-2040
 URL: https://issues.apache.org/jira/browse/TUSCANY-2040
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Samples
Affects Versions: Java-SCA-Next
Reporter: Venkatakrishnan


The continium build has failed when building the Apache Tuscany SCA HelloWorld 
Web Service JMS Sample.  The reason seems to be because this sample use the 
port 8080 which seems to be in use on the Continuum Server.  For more details - 
http://mail.google.com/mail/?ui=2&ik=11441ea30b&view=lg&msg=118068937ff670f9

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


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

RE: Tuscany: Axis2 codegen bug? - java interface exposed as service, annoted with javax.xml.ws.RequestWrapper(...) is not honoring the namespace

[Clemens Utschig - Utschig]

given that I have a full testcase on my box with SDO generated through oracle 
adf bc, I guess I am happy to play guinea pig ..

/clemens

-Original Message-
From: Raymond Feng [mailto:[EMAIL PROTECTED]
Sent: Sunday, February 10, 2008 9:56 PM
To: tuscany-dev@ws.apache.org
Subject: Re: Tuscany: Axis2 codegen bug? - java interface exposed as
service, annoted with javax.xml.ws.RequestWrapper(...) is not honoring
the namespace


Hi,

I think we have two issues here:

1) Generate the WSDL port type from a java interface following the JAX-WS
mapping rules (JSR-181 annotations can be used to customize the WSDL). The
SCA spec chooses JAX-WS to map between remotable java interfaces and WSDLs.
I assume Simon's proposal is for this step.

2) Generate or map the XML Schema for the java parameter types, return type
and exception types. The data can be represented by different databindings
such as JAXB, SDO or XMLBeans. Some of them have metadata for the XML
elements/types such as JAXB annotations and SDO Type/Property. We need to
make sure the generated XSDs are consistent with these information. The
Java2XSD should be pluggable based on the databindings.

Thanks,
Raymond

- Original Message -
From: "Simon Nash" <[EMAIL PROTECTED]>
To: 
Sent: Sunday, February 10, 2008 12:42 PM
Subject: Re: Tuscany: Axis2 codegen bug? - java interface exposed as
service, annoted with javax.xml.ws.RequestWrapper(...) is not honoring the
namespace


> Jean-Sebastien Delfino wrote:
>> Clemens Utschig - Utschig wrote:
>>> Folks,
>>>
>>> I have a simple composite as below - which makes use of SDO through SOAP
>>> in the reference
>>>
>>> 
>>> http://www.osoa.org/xmlns/sca/1.0";
>>>targetNamespace="/model/common/"
>>>
>>> xmlns:dbsdo="http://tuscany.apache.org/xmlns/sca/databinding/sdo/1.0";
>>>name="FlexEmployeeComposite" xmlns:tns="/model/common/types/"
>>>xmlns:types="/model/common/types/"
>>>xmlns:errors="http://xmlns.oracle.com/adf/svc/errors/";
>>>xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/";>
>>>   
>>> >> class="com.oracle.soa.test.tuscany.impl.EmployeeServiceComponent"/>
>>> 
>>>   
>>>   >>  promote="FlexEmployeeServiceComponent/empFlexFieldService">
>>> >> interface="model.common.serviceinterface.EmpFlexFieldService"/>
>>> >> uri="http://localhost:1234/Application4710-Model-context-root/EmpFlexFieldService"/>
>>>   
>>> 
>>>
>>> that promotes the java interface from the reference as service .. the
>>> interface is annotated as webservice - as below ..
>>>
>>>@javax.jws.WebMethod(action="/model/common/createEmployees1",
>>> operationName="createEmployees1")
>>> @javax.xml.ws.RequestWrapper(targetNamespace="/model/common/types/",
>>> localName="createEmployees1")
>>>
>>> @javax.xml.ws.ResponseWrapper(targetNamespace="/model/common/types/",
>>> localName="createEmployees1Response")
>>> @javax.jws.WebResult(name="result")
>>> DataObject
>>> createEmployees1(@javax.jws.WebParam(mode=javax.jws.WebParam.Mode.IN,
>>> name="employees1")
>>> DataObject employees1) throws ServiceException;
>>>
>>> which implies that the namespace for this element is
>>> "/model/common/types/"
>>>
>>> however - Axis2, takes the targetNamespace - and hence tries to send out
>>>
>>> 
>>> >> xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/";>
>>> 
>>> <_ns_:getEmployees1 xmlns:_ns_="/model/common/">
>>> 1
>>> 
>>> 
>>> 
>>>
>>>
>>> instead of
>>>
>>> http://schemas.xmlsoap.org/soap/envelope/";>
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>>
>>> anybody seen this? - this sounds like a real bug to me..
>>>
>>> thx clemens
>>
>> I'm not sure that the support for jaxws annotations is ready and
>> integrated in the build yet, although it may be pretty close.
>>
>> Raymond, it looks like you've been working on the interface-java-jaxws
>> module recently, can you give us its status?
>>
>> Thanks.
>>
> I don't think the code in the interface-java-jaxws module is enough to
> solve this problem.  We also need the ability to generate a WSDL interface
> at runtime from a Java interface containing JAX-WS annotations.  (Our
> current code for this uses Axis2, which doesn't understand JAX-WS
> annotations.)  The code we need would do the same as the JAX-WS tool
> wsgen -wsdl, or the CXF tool java2wsdl, except that the processing would
> be done at runtime and would generate WSDL to a stream instead of a file.
>
> From a quick look at both these options, it looks like it would be
> possible for the Tuscany runtime to call into code from either CXF or
> the JAX-WS tools to do the generation.  However, this wouldn't be using
> any official APIs but would require a bit of copying and adapting the code
> that is currently there.  Of the two options, the CXF code seems rather
> easier to work with.  Also, since CXF is an Apache project, Tuscany could
> contribute back to CXF any modifications we ma

Re: Tuscany: Axis2 codegen bug? - java interface exposed as service, annoted with javax.xml.ws.RequestWrapper(...) is not honoring the namespace

[Raymond Feng]

Hi,

I think we have two issues here:

1) Generate the WSDL port type from a java interface following the JAX-WS 
mapping rules (JSR-181 annotations can be used to customize the WSDL). The 
SCA spec chooses JAX-WS to map between remotable java interfaces and WSDLs. 
I assume Simon's proposal is for this step.


2) Generate or map the XML Schema for the java parameter types, return type 
and exception types. The data can be represented by different databindings 
such as JAXB, SDO or XMLBeans. Some of them have metadata for the XML 
elements/types such as JAXB annotations and SDO Type/Property. We need to 
make sure the generated XSDs are consistent with these information. The 
Java2XSD should be pluggable based on the databindings.


Thanks,
Raymond

- Original Message - 
From: "Simon Nash" <[EMAIL PROTECTED]>

To: 
Sent: Sunday, February 10, 2008 12:42 PM
Subject: Re: Tuscany: Axis2 codegen bug? - java interface exposed as 
service, annoted with javax.xml.ws.RequestWrapper(...) is not honoring the 
namespace




Jean-Sebastien Delfino wrote:

Clemens Utschig - Utschig wrote:

Folks,

I have a simple composite as below - which makes use of SDO through SOAP 
in the reference



http://www.osoa.org/xmlns/sca/1.0";
   targetNamespace="/model/common/"

xmlns:dbsdo="http://tuscany.apache.org/xmlns/sca/databinding/sdo/1.0";
   name="FlexEmployeeComposite" xmlns:tns="/model/common/types/"
   xmlns:types="/model/common/types/"
   xmlns:errors="http://xmlns.oracle.com/adf/svc/errors/";
   xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/";>
  
class="com.oracle.soa.test.tuscany.impl.EmployeeServiceComponent"/>


  
  
interface="model.common.serviceinterface.EmpFlexFieldService"/>
uri="http://localhost:1234/Application4710-Model-context-root/EmpFlexFieldService"/>

  


that promotes the java interface from the reference as service .. the 
interface is annotated as webservice - as below ..


   @javax.jws.WebMethod(action="/model/common/createEmployees1",
operationName="createEmployees1")
@javax.xml.ws.RequestWrapper(targetNamespace="/model/common/types/",
localName="createEmployees1")

@javax.xml.ws.ResponseWrapper(targetNamespace="/model/common/types/",
localName="createEmployees1Response")
@javax.jws.WebResult(name="result")
DataObject 
createEmployees1(@javax.jws.WebParam(mode=javax.jws.WebParam.Mode.IN, 
name="employees1")

DataObject employees1) throws ServiceException;

which implies that the namespace for this element is 
"/model/common/types/"


however - Axis2, takes the targetNamespace - and hence tries to send out


xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/";>


<_ns_:getEmployees1 xmlns:_ns_="/model/common/">
1





instead of

http://schemas.xmlsoap.org/soap/envelope/";>







anybody seen this? - this sounds like a real bug to me..

thx clemens


I'm not sure that the support for jaxws annotations is ready and
integrated in the build yet, although it may be pretty close.

Raymond, it looks like you've been working on the interface-java-jaxws
module recently, can you give us its status?

Thanks.


I don't think the code in the interface-java-jaxws module is enough to
solve this problem.  We also need the ability to generate a WSDL interface
at runtime from a Java interface containing JAX-WS annotations.  (Our
current code for this uses Axis2, which doesn't understand JAX-WS
annotations.)  The code we need would do the same as the JAX-WS tool
wsgen -wsdl, or the CXF tool java2wsdl, except that the processing would
be done at runtime and would generate WSDL to a stream instead of a file.

From a quick look at both these options, it looks like it would be
possible for the Tuscany runtime to call into code from either CXF or
the JAX-WS tools to do the generation.  However, this wouldn't be using
any official APIs but would require a bit of copying and adapting the code
that is currently there.  Of the two options, the CXF code seems rather
easier to work with.  Also, since CXF is an Apache project, Tuscany could
contribute back to CXF any modifications we make to enable this.

Before I launch into actually trying to get this working, does anyone
else have comments or suggestions on the general approach?

 Simon


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




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

Re: svn commit: r620376 - /incubator/tuscany/java/sca/modules/host-webapp/src/main/java/org/apache/tuscany/sca/host/webapp/WebAppServletHost.java

[Raymond Feng]

Hi,

I don't think this is a good fix. The ServletContext.getContextPath() is 
introduced for Servlet Spec 2.5 or later. The major/minor version can tell 
us if the current ServletContext has getContextPath() method. In Servlet 
2.4, the getContextPath() is only available on HttpServletRequest.


With this change, we'll get IllegalStateException for Servlet version before 
2.5. Is the WebSphere Servlet at the level of 2.5 or later? If so, the 
getContextPath() should return a valid value as required by the spec. (See 
[1]). If it returns null, it should be a WebSphere bug :-).


BTW, I don't know why we check the init-parameter for the contextPath as a 
fall-back. Is it a Tuscany specific thing or a Servlet spec statement (I 
couldn't find it in Servlet spec 2.4)?


Thanks,
Raymond

[1] 
http://java.sun.com/javaee/5/docs/api/javax/servlet/ServletContext.html#getContextPath()


- Original Message - 
From: <[EMAIL PROTECTED]>

To: <[EMAIL PROTECTED]>
Sent: Sunday, February 10, 2008 6:06 PM
Subject: svn commit: r620376 - 
/incubator/tuscany/java/sca/modules/host-webapp/src/main/java/org/apache/tuscany/sca/host/webapp/WebAppServletHost.java




Author: lresende
Date: Sun Feb 10 18:06:37 2008
New Revision: 620376

URL: http://svn.apache.org/viewvc?rev=620376&view=rev
Log:
Comment code that was failing to retrieve contextPath in certain web 
containers


Modified:

incubator/tuscany/java/sca/modules/host-webapp/src/main/java/org/apache/tuscany/sca/host/webapp/WebAppServletHost.java

Modified: 
incubator/tuscany/java/sca/modules/host-webapp/src/main/java/org/apache/tuscany/sca/host/webapp/WebAppServletHost.java
URL: 
http://svn.apache.org/viewvc/incubator/tuscany/java/sca/modules/host-webapp/src/main/java/org/apache/tuscany/sca/host/webapp/WebAppServletHost.java?rev=620376&r1=620375&r2=620376&view=diff

==
---  
incubator/tuscany/java/sca/modules/host-webapp/src/main/java/org/apache/tuscany/sca/host/webapp/WebAppServletHost.java 
(original)
+++ 
incubator/tuscany/java/sca/modules/host-webapp/src/main/java/org/apache/tuscany/sca/host/webapp/WebAppServletHost.java 
Sun Feb 10 18:06:37 2008

@@ -240,7 +240,8 @@
public void initContextPath(ServletConfig config) {
ServletContext context = config.getServletContext();
int version = context.getMajorVersion() * 100 + 
context.getMinorVersion();

-if (version >= 205) {
+//FIXME Do we really need this ? Servlet 2.4 Spec does mention 
getContextPath

+//if (version >= 205) {
// The getContextPath() is introduced since Servlet 2.5
Method m;
try {
@@ -254,9 +255,9 @@
throw new IllegalStateException(
"'contextPath' init 
parameter must be set for pre-2.5 servlet container");

}
-} else {
-contextPath = config.getInitParameter("contextPath");
-}
+//} else {
+//contextPath = config.getInitParameter("contextPath");
+//}
logger.info("initContextPath: " + contextPath);
}




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




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

Re: [PROPOSAL] Automate itests for WAR packaging

[Luciano Resende]

I have added automation support for the Websphere platform. The
automation uses some python scripts to integrate with WAS admin tools
and can start the server, deploy the iTest web application, undeploy
the application and stop the server. There are still two issues that
needs to be addressed :

1) Executing the unit tests are not working yet, and are throwing exceptions :
- Error 500:
com.ibm.ws.wswebcontainer.extension.DefaultExtensionProcessor
incompatible with com.ibm.wsspi.webcontainer.servlet.IServletWrapper

2) There are issues trying to run the automation from a folder other
then the iTest folder, as the ant scripts reference the ant scripts
and python scripts as relative paths, and when running from a
different folder, they can't be found.

To run, execute the following maven command from the iTest folder :

mvn -Pwebapp,websphere clean install

Note: for websphere, you should have WAS_HOME env variable set properly.







On Feb 5, 2008 5:40 PM, Luciano Resende <[EMAIL PROTECTED]> wrote:
> We now have the iTest pom handling all the configuration for running
> the execution of the iTests in a web-container. At the moment, we have
> enabled selected iTests (services and componentType) and you can
> execute the tests in Geronimo and/or Jetty. Adding new iTests should
> be as simple as adding it to the module list of the webApp profile,
> but we might find issues when experimenting with ws and other bindings
> (port issues for example). To execute the tests, use the webApp
> profile + the web-container you want to test on (Geronimo or Jetty)
> under the iTest folder.
>
> mvn -Pwebapp,geronimo clean install
>
> Note : for geronimo, you should have GERONIMO_HOME env variable set
> properly. I now looking into getting the same integration with
> Websphere App Server.
>
>
> On Feb 5, 2008 3:35 AM, Simon Nash <[EMAIL PROTECTED]> wrote:
> > ant elder wrote:
> > > Could you say a bit more about why it needs to be a runtime module not 
> > > just
> > > somewhere like maven-web-junit, and what the issue is in point 3? (as you
> > > can guess my preference is for this to not be in the core runtime :))
> > >
> > >...ant
> > >
> > I agree that we should keep this out of the core runtime if possible.
> > The "get it working now, refactor later" approach sounds attractive
> > but in practice it's hard to prioritize refactoring something that
> > already works when we have so many other things that also need to
> > be done.
> >
> >Simon
> >
> >
> > > On Feb 4, 2008 9:57 PM, Raymond Feng <[EMAIL PROTECTED]> wrote:
> > >
> > >> Hi,
> > >>
> > >> I don't have a strong preference. Let's try to get the basic function
> > >> working well first. A few points to think about before we refactor it.
> > >>
> > >> 1) maven-web-junit is a maven plugin under tools. We need to add another
> > >> runtime project under modules folder.
> > >> 2) host-webapp adds the junit as a runtime dependency which is not great
> > >> but
> > >> not too bad.
> > >> 3) Configuring two servlet filters conditionally is a bit complex :-). We
> > >> can also disable the /junit unit with an init-parameter "junit.enabled"
> > >> set
> > >> to false.
> > >>
> > >> Thanks,
> > >> Raymond
> > >>
> > >> - Original Message -
> > >> From: "ant elder" <[EMAIL PROTECTED]>
> > >> To: 
> > >> Sent: Monday, February 04, 2008 7:14 AM
> > >> Subject: Re: [PROPOSAL] Automate itests for WAR packaging
> > >>
> > >>
> > >>> If this is just for itests then to keep runtime cleaner how about moving
> > >>> it
> > >>> all out of the main runtime code into the maven-web-junit module? So
> > >> move
> > >>> WebTestRunner, XMLFormatter, add a new ITestTuscanyServletFilter that
> > >>> extends the TuscanyServletFilter to add the /junit hook and revert
> > >>> host-webapp, and the web.xml in the itest/services module can refer to
> > >> the
> > >>> new  ITestTuscanyServletFilter?
> > >>>
> > >>>   ...ant
> > >>>
> >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
>
> --
> Luciano Resende
> Apache Tuscany Committer
> http://people.apache.org/~lresende
> http://lresende.blogspot.com/
>



-- 
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: Binding-echo-extension failing : missing abstract method getApplicablePolicySets() Fwd: [continuum] BUILD FAILURE: Apache Tuscany SCA Implementation Project

[Venkata Krishnan]

Thanks.  I will ask Sebastien then :)

- Venkat

On Feb 11, 2008 8:07 AM, Luciano Resende <[EMAIL PROTECTED]> wrote:

> On Feb 10, 2008 5:50 PM, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > Yes.  But I had checked in the changes to the samples as well.
> >
> > I have an ID on the continuum server, but can't start builds myself.
>  Those
> > options don't seem to be enbled for me.
> >
> > Thanks
> >
> > - Venkat
> >
>
> If you are logged in to continuum, you should be able to start a
> build. otherwise, Sebastien or another continuum administrator might
> be able to give you proper karma as my account is locked out :(
>
> --
> 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: Error trying to initialize Tuscany web-apps that uses ws-binding

[Luciano Resende]

Fixed under revision #620376

On Feb 10, 2008 12:26 PM, Luciano Resende <[EMAIL PROTECTED]> wrote:
> On Feb 9, 2008 1:47 AM, ant elder <[EMAIL PROTECTED]> wrote:
> > On Feb 8, 2008 6:29 PM, Luciano Resende <[EMAIL PROTECTED]> wrote:
> >
> > > I was trying our calculator-ws-secure-webapp and calculator-ws-webapp
> > > in various web application hosts, and looks like it works fine in
> > > Tomcat 6.0.16, Geronimo 2.0.2, but it's failing in Websphere 6.1 with
> > > the following exception. I'll try to debug later today, but just want
> > > to mention here in case others might have seen this and have some
> > > tips. I hope this is a configuration issue only. I also verified that
> > > the same web-app from 1.1 release works ok.
> > >
> >
> > Just to clarify, are you saying this works with the 1.1 release but not in
> > the trunk code?
> >
>
> Yes
>
> > I'd guess this will be due to differences with the base url and context path
> > in WebSphere but haven't noticed any related changes since 1.1. Would also
> > be interesting to see if ?wsdl returns wsdl containing the different port
> > endpoints in the  different environments.
> >
>
> This was introduced by the revision #619602, where we check the
> version of Servlet API in use, and if it's prior to 2.5, we use the
> code below to retrieve the web app contextPath, and in WAS environment
> we are not retrieving the proper application contextPath.
>
> int version = context.getMajorVersion() * 100 +
> context.getMinorVersion();
> if (version >= 205) {
> 
> } else {
> contextPath = config.getInitParameter("contextPath");
> }
>
>
> >...ant
>
> >
>
>
>
> --
> Luciano Resende
> Apache Tuscany Committer
> http://people.apache.org/~lresende
> http://lresende.blogspot.com/
>



-- 
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: Binding-echo-extension failing : missing abstract method getApplicablePolicySets() Fwd: [continuum] BUILD FAILURE: Apache Tuscany SCA Implementation Project

[Luciano Resende]

On Feb 10, 2008 5:50 PM, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Yes.  But I had checked in the changes to the samples as well.
>
> I have an ID on the continuum server, but can't start builds myself.  Those
> options don't seem to be enbled for me.
>
> Thanks
>
> - Venkat
>

If you are logged in to continuum, you should be able to start a
build. otherwise, Sebastien or another continuum administrator might
be able to give you proper karma as my account is locked out :(

-- 
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: Tuscany: Axis2 codegen bug? - java interface exposed as service, annoted with javax.xml.ws.RequestWrapper(...) is not honoring the namespace

[Clemens Utschig - Utschig]

would it help to have a interface.wsdl? that contains the whole thing - rather 
than generating it from the annonated java interface?

-- if so, any example for that?

cherrs clemens

-Original Message-
From: Simon Nash [mailto:[EMAIL PROTECTED]
Sent: Sunday, February 10, 2008 12:42 PM
To: tuscany-dev@ws.apache.org
Subject: Re: Tuscany: Axis2 codegen bug? - java interface exposed as service, 
annoted with javax.xml.ws.RequestWrapper(...) is not honoring the namespace


Jean-Sebastien Delfino wrote:
> Clemens Utschig - Utschig wrote:
>> Folks,
>>
>> I have a simple composite as below - which makes use of SDO through SOAP in 
>> the reference
>>
>> 
>> http://www.osoa.org/xmlns/sca/1.0";
>>targetNamespace="/model/common/"
>>
>> xmlns:dbsdo="http://tuscany.apache.org/xmlns/sca/databinding/sdo/1.0";
>>name="FlexEmployeeComposite" xmlns:tns="/model/common/types/"
>>xmlns:types="/model/common/types/"
>>xmlns:errors="http://xmlns.oracle.com/adf/svc/errors/";
>>xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/";>
>>   
>> > class="com.oracle.soa.test.tuscany.impl.EmployeeServiceComponent"/>
>> 
>>   
>>   >  promote="FlexEmployeeServiceComponent/empFlexFieldService">
>> > interface="model.common.serviceinterface.EmpFlexFieldService"/>
>> > uri="http://localhost:1234/Application4710-Model-context-root/EmpFlexFieldService"/>
>>   
>> 
>>
>> that promotes the java interface from the reference as service .. the 
>> interface is annotated as webservice - as below ..
>>
>>@javax.jws.WebMethod(action="/model/common/createEmployees1",
>> operationName="createEmployees1")
>> @javax.xml.ws.RequestWrapper(targetNamespace="/model/common/types/",
>> localName="createEmployees1")
>> @javax.xml.ws.ResponseWrapper(targetNamespace="/model/common/types/",
>> localName="createEmployees1Response")
>> @javax.jws.WebResult(name="result")
>> DataObject 
>> createEmployees1(@javax.jws.WebParam(mode=javax.jws.WebParam.Mode.IN, 
>> name="employees1")
>> DataObject employees1) throws ServiceException;
>>
>> which implies that the namespace for this element is "/model/common/types/"
>>
>> however - Axis2, takes the targetNamespace - and hence tries to send out
>>
>>  
>>  > xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/";>
>>  
>>  <_ns_:getEmployees1 xmlns:_ns_="/model/common/">
>>  1
>>  
>>  
>>  
>>
>>
>> instead of
>>
>> http://schemas.xmlsoap.org/soap/envelope/";>
>> 
>> 
>> 
>> 
>> 
>> 
>>
>> anybody seen this? - this sounds like a real bug to me..
>>
>> thx clemens
>
> I'm not sure that the support for jaxws annotations is ready and
> integrated in the build yet, although it may be pretty close.
>
> Raymond, it looks like you've been working on the interface-java-jaxws
> module recently, can you give us its status?
>
> Thanks.
>
I don't think the code in the interface-java-jaxws module is enough to
solve this problem.  We also need the ability to generate a WSDL interface
at runtime from a Java interface containing JAX-WS annotations.  (Our
current code for this uses Axis2, which doesn't understand JAX-WS
annotations.)  The code we need would do the same as the JAX-WS tool
wsgen -wsdl, or the CXF tool java2wsdl, except that the processing would
be done at runtime and would generate WSDL to a stream instead of a file.

From a quick look at both these options, it looks like it would be
possible for the Tuscany runtime to call into code from either CXF or
the JAX-WS tools to do the generation.  However, this wouldn't be using
any official APIs but would require a bit of copying and adapting the code
that is currently there.  Of the two options, the CXF code seems rather
easier to work with.  Also, since CXF is an Apache project, Tuscany could
contribute back to CXF any modifications we make to enable this.

Before I launch into actually trying to get this working, does anyone
else have comments or suggestions on the general approach?

  Simon


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

[jira] Deleted: (TUSCANY-2039) Generated sample files should not be checked into svn

[Simon Nash (JIRA)]

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

Simon Nash deleted TUSCANY-2039:



> Generated sample files should not be checked into svn
> -
>
> Key: TUSCANY-2039
> URL: https://issues.apache.org/jira/browse/TUSCANY-2039
> Project: Tuscany
>  Issue Type: Bug
> Environment: all
>Reporter: Simon Nash
>Priority: Minor
>
> The following generated files are checked into svn:
>   samples/calculator-webapp/build.xml
>   samples/calculator-ws-webapp/build.xml
>   samples/chat-webapp/build.xml
>   samples/feed-aggregator-webapp/build.xml
>   samples/helloworld-dojo-webapp/build-dependency.xml
>   samples/helloworld-jsonrpc-webapp/build.xml
>   samples/helloworld-ws-sdo-webapp/build.xml
> Generated files hould not be checked into svn as every change to their 
> contents requires an update of the repository copy when using the 
> command-line svn client to perform checkins.

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


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

[jira] Created: (TUSCANY-2039) Generated sample files should not be checked into svn

[Simon Nash (JIRA)]

Generated sample files should not be checked into svn
-

 Key: TUSCANY-2039
 URL: https://issues.apache.org/jira/browse/TUSCANY-2039
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Samples
Affects Versions: Java-SCA-Next
 Environment: all
Reporter: Simon Nash
Priority: Minor
 Fix For: Java-SCA-Next


The following generated files are checked into svn:
  samples/calculator-webapp/build.xml
  samples/calculator-ws-webapp/build.xml
  samples/chat-webapp/build.xml
  samples/feed-aggregator-webapp/build.xml
  samples/helloworld-dojo-webapp/build-dependency.xml
  samples/helloworld-jsonrpc-webapp/build.xml
  samples/helloworld-ws-sdo-webapp/build.xml

Generated files hould not be checked into svn as every change to their contents 
requires an update of the repository copy when using the command-line svn 
client to perform checkins.

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


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

[jira] Resolved: (TUSCANY-2038) Conversations itest runs out of memory with 64-bit JVM

[Simon Nash (JIRA)]

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

Simon Nash resolved TUSCANY-2038.
-

Resolution: Fixed

The surefire plugin condiguration specified -Xmx128m.  Changed this to -Xmx256m 
as a 64-bit JVM can potentially use up to double the amount of memory used by a 
32-bit JVM.  Fix committed as revision 620352.

> Conversations itest runs out of memory with 64-bit JVM
> --
>
> Key: TUSCANY-2038
> URL: https://issues.apache.org/jira/browse/TUSCANY-2038
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Integration Tests
>Affects Versions: Java-SCA-1.1
> Environment: Windows 64-bit
>Reporter: Simon Nash
>Assignee: Simon Nash
>Priority: Minor
> Fix For: Java-SCA-Next
>
>
> The conversations itest runs out of memory when using a 64-bit JVM.  It runs 
> OK with a 32-bit JVM.

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


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

[jira] Created: (TUSCANY-2038) Conversations itest runs out of memory with 64-bit JVM

[Simon Nash (JIRA)]

Conversations itest runs out of memory with 64-bit JVM
--

 Key: TUSCANY-2038
 URL: https://issues.apache.org/jira/browse/TUSCANY-2038
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Integration Tests
Affects Versions: Java-SCA-1.1
 Environment: Windows 64-bit
Reporter: Simon Nash
Assignee: Simon Nash
Priority: Minor
 Fix For: Java-SCA-Next


The conversations itest runs out of memory when using a 64-bit JVM.  It runs OK 
with a 32-bit JVM.

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


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

[jira] Assigned: (TUSCANY-2034) NPE while namespace creation in

[Simon Nash (JIRA)]

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

Simon Nash reassigned TUSCANY-2034:
---

Assignee: Simon Nash

> NPE while namespace creation in 
> 
>
> Key: TUSCANY-2034
> URL: https://issues.apache.org/jira/browse/TUSCANY-2034
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Axis Binding Extension
>Affects Versions: Java-SCA-1.0.1
>Reporter: clemens utschig
>Assignee: Simon Nash
> Fix For: Java-SCA-1.1
>
> Attachments: Java2WSDLHelper.java
>
>
> when the wsdl is generated from a java interface, and the namespace pairs 
> generated - I get a nullpointer exception in my enviroment.
> Caused by: java.lang.NullPointerException
>   at 
> org.apache.tuscany.sca.interfacedef.wsdl.java2wsdl.Java2WSDLHelper.promote(Java2WSDLHelper.java:196)
>   at 
> org.apache.tuscany.sca.interfacedef.wsdl.java2wsdl.Java2WSDLHelper.readInlineSchemas(Java2WSDLHelper.java:236)
>   at 
> org.apache.tuscany.sca.interfacedef.wsdl.java2wsdl.Java2WSDLHelper.createWSDLInterfaceContract(Java2WSDLHelper.java:145)
>   at 
> org.apache.tuscany.sca.binding.ws.axis2.Axis2ReferenceBindingProvider.(Axis2ReferenceBindingProvider.java:51)
>   at 
> org.apache.tuscany.sca.binding.ws.axis2.Axis2BindingProviderFactory.createReferenceBindingProvider(Axis2BindingProviderFactory.java:53)
>   at 
> org.apache.tuscany.sca.binding.ws.axis2.Axis2BindingProviderFactory.createReferenceBindingProvider(Axis2BindingProviderFactory.java:40)
>   at 
> org.apache.tuscany.sca.provider.DefaultProviderFactoryExtensionPoint$LazyBindingProviderFactory.createReferenceBindingProvider(DefaultProviderFactoryExtensionPoint.java:190)
>   at 
> org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.addReferenceBindingProvider(CompositeActivatorImpl.java:176)
>   at 
> org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.activate(CompositeActivatorImpl.java:133)
>   at 
> org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.activate(CompositeActivatorImpl.java:752)
> this happens when the nodeMap from  NamedNodeMap nodeMap = 
> root.getAttributes(); is null - and when the element.getNodeName == 
> "#document" - and hence has no attributes.
> adding a nullcheck fixes this ..

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


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

[jira] Resolved: (TUSCANY-2034) NPE while namespace creation in

[Simon Nash (JIRA)]

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

Simon Nash resolved TUSCANY-2034.
-

Resolution: Fixed

Thanks for the patch.  Patch applied in revision 620350.

> NPE while namespace creation in 
> 
>
> Key: TUSCANY-2034
> URL: https://issues.apache.org/jira/browse/TUSCANY-2034
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Axis Binding Extension
>Affects Versions: Java-SCA-1.0.1
>Reporter: clemens utschig
>Assignee: Simon Nash
> Fix For: Java-SCA-1.1
>
> Attachments: Java2WSDLHelper.java
>
>
> when the wsdl is generated from a java interface, and the namespace pairs 
> generated - I get a nullpointer exception in my enviroment.
> Caused by: java.lang.NullPointerException
>   at 
> org.apache.tuscany.sca.interfacedef.wsdl.java2wsdl.Java2WSDLHelper.promote(Java2WSDLHelper.java:196)
>   at 
> org.apache.tuscany.sca.interfacedef.wsdl.java2wsdl.Java2WSDLHelper.readInlineSchemas(Java2WSDLHelper.java:236)
>   at 
> org.apache.tuscany.sca.interfacedef.wsdl.java2wsdl.Java2WSDLHelper.createWSDLInterfaceContract(Java2WSDLHelper.java:145)
>   at 
> org.apache.tuscany.sca.binding.ws.axis2.Axis2ReferenceBindingProvider.(Axis2ReferenceBindingProvider.java:51)
>   at 
> org.apache.tuscany.sca.binding.ws.axis2.Axis2BindingProviderFactory.createReferenceBindingProvider(Axis2BindingProviderFactory.java:53)
>   at 
> org.apache.tuscany.sca.binding.ws.axis2.Axis2BindingProviderFactory.createReferenceBindingProvider(Axis2BindingProviderFactory.java:40)
>   at 
> org.apache.tuscany.sca.provider.DefaultProviderFactoryExtensionPoint$LazyBindingProviderFactory.createReferenceBindingProvider(DefaultProviderFactoryExtensionPoint.java:190)
>   at 
> org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.addReferenceBindingProvider(CompositeActivatorImpl.java:176)
>   at 
> org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.activate(CompositeActivatorImpl.java:133)
>   at 
> org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.activate(CompositeActivatorImpl.java:752)
> this happens when the nodeMap from  NamedNodeMap nodeMap = 
> root.getAttributes(); is null - and when the element.getNodeName == 
> "#document" - and hence has no attributes.
> adding a nullcheck fixes this ..

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


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

[jira] Resolved: (TUSCANY-2037) calculator-ws-secure-webapp has checked in copy of generated build.xml

[Simon Nash (JIRA)]

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

Simon Nash resolved TUSCANY-2037.
-

Resolution: Fixed

Fixed in revision 620349.

> calculator-ws-secure-webapp has checked in copy of generated build.xml
> --
>
> Key: TUSCANY-2037
> URL: https://issues.apache.org/jira/browse/TUSCANY-2037
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Samples
>Affects Versions: Java-SCA-1.1
> Environment: Windows
>Reporter: Simon Nash
>Assignee: Simon Nash
>Priority: Minor
> Fix For: Java-SCA-Next
>
>
> The calculator-ws-secure-webapp sample generates its build.xml.  This file 
> should not also be checked into svn.

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


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

[jira] Created: (TUSCANY-2037) calculator-ws-secure-webapp has checked in copy of generated build.xml

[Simon Nash (JIRA)]

calculator-ws-secure-webapp has checked in copy of generated build.xml
--

 Key: TUSCANY-2037
 URL: https://issues.apache.org/jira/browse/TUSCANY-2037
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Samples
Affects Versions: Java-SCA-1.1
 Environment: Windows
Reporter: Simon Nash
Assignee: Simon Nash
Priority: Minor
 Fix For: Java-SCA-Next


The calculator-ws-secure-webapp sample generates its build.xml.  This file 
should not also be checked into svn.

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


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

[jira] Created: (TUSCANY-2036) calculator-ws-secure-webapp generates build.xml with two different versions of stax-api

[Simon Nash (JIRA)]

calculator-ws-secure-webapp generates build.xml with two different versions of 
stax-api
---

 Key: TUSCANY-2036
 URL: https://issues.apache.org/jira/browse/TUSCANY-2036
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Samples
Affects Versions: Java-SCA-1.1
 Environment: Windows
Reporter: Simon Nash
Priority: Minor
 Fix For: Java-SCA-Next


The build.xml file generated by the calculator-ws-secure-webapp sample includes 
the following different versions of the stax-api dependency. 



One of these should be eliminated.

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


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

Re: Distribution zips and what they contain, was: SCA runtimes

[Simon Nash]

Comments inline.

  Simon

Jean-Sebastien Delfino wrote:

Mike Edwards wrote:

Jean-Sebastien,

Let's chat some more about objectives, to see why we're seeming to 
look at this differently:




[snip]

Jean-Sebastien Delfino wrote:
I was thinking about the following binary distro zips:

- tuscany-core.zip - The base that everybody needs.
  core assembly model and runtime
  Java APIs, Java components

- tuscany-web.zip - For WS and Web developers
  WS binding, Web 2.0 bindings, Scripting components, Widget 
components


- tuscany-jee.zip - For JEE app integration
  EJB, RMI and JMS bindings, Spring components

- tuscany-process.zip - For process development
  BPEL and XQuery components

- tuscany-all.zip - all of the above




Mike Edwards wrote:
I'm not convinced that this is a particularly useful split.  Sorry 
to disagree, but it is worth debating this before folk do a lot of 
work.


 From the perspective of an end-user, their main goal in life is to 
get their applications working on their runtime.


I view this as something like:

- give me a Tuscany package (containing the Tuscany runtime 
materials) and a way of installing that with my runtime.  Then tell 
me how and where I put my application stuff so that it will run.


- splitting up the Tuscany package into several packages does not 
seem to help me very much.  Now I have to go read and understand 
what each package does and what I need to do with it.


- let's envisage a series of potential runtimes which I could be using:
a) standalone Tuscany
b) Tomcat
c) Geronimo
d) WebSphere
e) a. n. other runtime
What I think I'd really like is to be told
1) go get this (one) download package containing the runtime
2) have an install script of some kind that knows how to take 
content from the download package and put it "in the right place(s)" 
for it to be usable with my runtime (may be one script per runtime 
type)


- the partitioning which Jean-Sebastien describes above is actually 
more appropriately done by the install script.  It will either KNOW 
that only certain pieces are appropriate for a given runtime (eg no 
point in installing JEE related stuff on a non-JEE runtime), or it 
will be able to ask some simple questions about whether I will need 
some of the less common pieces


- am I asking for too much here, or is this the best approach for 
the end users?





Jean-Sebastien Delfino wrote:
Sorry, I'm not convinced:

- The packages I've proposed are relevant to all the runtimes you've 
listed (including the JEE one).


- If I'm an application developer or a system administrator and I'm 
not able to say if I'm going to use Web 2.0, JEE integration or 
business processes, I won't be able to answer the install script 
questions either.


I find the organization of the Spring framework download page [1] 
clear and useful and I was envisioning a similar download page 
organization for Tuscany. Do people find it confusing and can they 
say why?


[1] http://www.springframework.org/download



Mike edwards wrote:

The problem I have with the Spring download page, which I think is the 
same as the reason I'm not keen on the split you've suggested above, 
is that I first have to get to grips with what each download is about.


So, if I'm a newbie to Spring, I first have to learn about "Web Flow", 
"Security", "Web Services" and so on, in order to know whether I need 
them or not.  For someone already familiar with Spring, this split 
might be OK.


I was thinking about two categories of users:

A) The user who knows what he wants to achieve:
- I am a Web app developer and want to compose a Web app
- I want to compose Web Services
- I want to integrate existing EJBs from my JEE app server
- I want to develop business processes

These packages would help him get the distro he needs.

B) The lurker who wants to try out Tuscany.

The different packages on the download page would give him an overview 
of the high-level features. He'd pick one path and start to explore it, 
instead of drowning in a sea of features and JARs that he doesn't need 
to start experimenting.


 For a newbie, it isn't.


Let's go back to the reason to want to split things up.  We've 
previously discussed:


- splitting to make the download smaller
- making it easier for people to find what they need

I've said before that I think making things easier for people should 
be the more important of the goals.  The trouble is that these 
requirements are actually in conflict.  The simplest package is a 
single package that I download and then run as an installer - and I 
get everything I want. No more searching.  No sudden discovery that 
something does not work because I don't have some needed dependency.


I agree that package size is important, but it is less important to me 
than making things easy.  Even 100Mb ain't too big a deal these days 
with Broadband a general commodity.  (Microsoft certainly seem to 
think so when you look at some of their update bundles !!).


I note Simon

[jira] Assigned: (TUSCANY-2028) Conversation does not continue if a Service Reference is passed as a return value (not as a parameter)

[Simon Laws (JIRA)]

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

Simon Laws reassigned TUSCANY-2028:
---

Assignee: Simon Laws

> Conversation does not continue if a Service Reference is passed as a return 
> value (not as a parameter)
> --
>
> Key: TUSCANY-2028
> URL: https://issues.apache.org/jira/browse/TUSCANY-2028
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Core Runtime
>Affects Versions: Java-SCA-1.0.1
> Environment: Windows XP SP2, Intel Core 2 CPU, 2.6, 2GB Ram, jdk 
> 1.5.0_10
>Reporter: Daniel Stucky
>Assignee: Simon Laws
> Fix For: Java-SCA-Next
>
> Attachments: test.zip
>
>
> I have 3 components: Alpha, Beta and Gamma, where Gamma's Interface is marked 
> with @Conversational and @Scope("CONVERSATION"). I want Alpha to call a 
> method on Beta that creates a conversation with Gamma and returns a reference 
> to Gamma. Then I want to reuse that conversation to Gamma from Alpha.
> Therefore I let Alpha call method Beta.getRef(). Inside this method, a 
> reference to Gamma is created via componentContext.getServiceReference() and 
> the conversation is initialized by calling method Gamma.init(). Beta.getRef() 
> returns a CallableReference. So far it works, but as soon as I call a 
> method on that reference from within Alpha, a new Conversation is 
> initialized, the Conversation created between Beta and Gamma is not reused.
> See the original post on the mailing list: 
> http://mail-archives.apache.org/mod_mbox/ws-tuscany-user/200802.mbox/[EMAIL 
> PROTECTED] 
> And the answer by Simon Laws: 
> http://mail-archives.apache.org/mod_mbox/ws-tuscany-user/200802.mbox/[EMAIL 
> PROTECTED]

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


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

[jira] Resolved: (TUSCANY-1999) ConversationAttributes and expiry doesn't work with Stateless Conversational components

[Simon Laws (JIRA)]

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

Simon Laws resolved TUSCANY-1999.
-

Resolution: Fixed

Ben, Thomas

Thanks you for the changes. I've checked the patch in.

 I made a few changes to the way that the ConversationAttributes are set on the 
conversation as the conversation is used slightly differently depending on 
whether the wire connects to a component that is 

1. Local
2. Remote but in the same node
3. Remote but in a different node

Give it a spin see if it still does what you need it to. I'll mark this JIRA as 
resolved now and we can either repoen it or raise a new one for further changes

Regards

Simon

> ConversationAttributes and expiry doesn't work with Stateless Conversational 
> components
> ---
>
> Key: TUSCANY-1999
> URL: https://issues.apache.org/jira/browse/TUSCANY-1999
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Core Runtime
>Affects Versions: Java-SCA-1.1
>Reporter: Ben Smith
>Assignee: Simon Laws
> Fix For: Java-SCA-Next
>
> Attachments: ConversationExpiry.patch
>
>
> In services that are marked as @Conversational yet have scope of STATELESS 
> the following problems occur
> Caused by: 
> org.apache.tuscany.sca.implementation.java.introspect.impl.InvalidConversationalImplementation:
>  Service is marked with @ConversationAttributes but the scope is not 
> @Scope("CONVERSATION")
>   at 
> org.apache.tuscany.sca.implementation.java.introspect.impl.ConversationProcessor.visitClass(ConversationProcessor.java:57)
> Also looking at the code it looks as if that expiring of conversations only 
> occurs with services that are of scope CONVERSATION. I believe that the above 
> should work with all services marked as @Conversational. 
> To fix this I'm thinking that the job of expiring conversations should be 
> moved from the ConversationalScopeContainer into the ConversationManager and 
> the check in the ConversationProcessor changed to check for the 
> @Conversational tag not @Scope("CONVERSATION")
> Ben

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


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

Re: Tuscany: Axis2 codegen bug? - java interface exposed as service, annoted with javax.xml.ws.RequestWrapper(...) is not honoring the namespace

[Simon Nash]

Jean-Sebastien Delfino wrote:
> Clemens Utschig - Utschig wrote:
>> Folks,
>>
>> I have a simple composite as below - which makes use of SDO through SOAP in 
>> the reference
>>
>> 
>> http://www.osoa.org/xmlns/sca/1.0";
>>targetNamespace="/model/common/"
>>
>> xmlns:dbsdo="http://tuscany.apache.org/xmlns/sca/databinding/sdo/1.0";
>>name="FlexEmployeeComposite" xmlns:tns="/model/common/types/"
>>xmlns:types="/model/common/types/"
>>xmlns:errors="http://xmlns.oracle.com/adf/svc/errors/";
>>xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/";>
>>   
>> > class="com.oracle.soa.test.tuscany.impl.EmployeeServiceComponent"/>
>> 
>>   
>>   >  promote="FlexEmployeeServiceComponent/empFlexFieldService">
>> > interface="model.common.serviceinterface.EmpFlexFieldService"/>
>> > uri="http://localhost:1234/Application4710-Model-context-root/EmpFlexFieldService"/>
>>   
>> 
>>
>> that promotes the java interface from the reference as service .. the 
>> interface is annotated as webservice - as below ..
>>
>>@javax.jws.WebMethod(action="/model/common/createEmployees1", 
>> operationName="createEmployees1")
>> @javax.xml.ws.RequestWrapper(targetNamespace="/model/common/types/", 
>> localName="createEmployees1")
>> @javax.xml.ws.ResponseWrapper(targetNamespace="/model/common/types/", 
>> localName="createEmployees1Response")
>> @javax.jws.WebResult(name="result")
>> DataObject 
>> createEmployees1(@javax.jws.WebParam(mode=javax.jws.WebParam.Mode.IN, 
>> name="employees1")
>> DataObject employees1) throws ServiceException;
>>
>> which implies that the namespace for this element is "/model/common/types/"
>>
>> however - Axis2, takes the targetNamespace - and hence tries to send out 
>>
>>  
>>  > xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/";>
>>  
>>  <_ns_:getEmployees1 xmlns:_ns_="/model/common/">
>>  1
>>  
>>  
>>  
>>
>>
>> instead of 
>>
>> http://schemas.xmlsoap.org/soap/envelope/";>
>> 
>> 
>> 
>> 
>> 
>> 
>>
>> anybody seen this? - this sounds like a real bug to me..
>>
>> thx clemens
> 
> I'm not sure that the support for jaxws annotations is ready and
> integrated in the build yet, although it may be pretty close.
> 
> Raymond, it looks like you've been working on the interface-java-jaxws
> module recently, can you give us its status?
> 
> Thanks.
>
I don't think the code in the interface-java-jaxws module is enough to
solve this problem.  We also need the ability to generate a WSDL interface
at runtime from a Java interface containing JAX-WS annotations.  (Our
current code for this uses Axis2, which doesn't understand JAX-WS
annotations.)  The code we need would do the same as the JAX-WS tool
wsgen -wsdl, or the CXF tool java2wsdl, except that the processing would
be done at runtime and would generate WSDL to a stream instead of a file.

>From a quick look at both these options, it looks like it would be
possible for the Tuscany runtime to call into code from either CXF or
the JAX-WS tools to do the generation.  However, this wouldn't be using
any official APIs but would require a bit of copying and adapting the code
that is currently there.  Of the two options, the CXF code seems rather
easier to work with.  Also, since CXF is an Apache project, Tuscany could
contribute back to CXF any modifications we make to enable this.

Before I launch into actually trying to get this working, does anyone
else have comments or suggestions on the general approach?

  Simon


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

Re: Error trying to initialize Tuscany web-apps that uses ws-binding

[Luciano Resende]

On Feb 9, 2008 1:47 AM, ant elder <[EMAIL PROTECTED]> wrote:
> On Feb 8, 2008 6:29 PM, Luciano Resende <[EMAIL PROTECTED]> wrote:
>
> > I was trying our calculator-ws-secure-webapp and calculator-ws-webapp
> > in various web application hosts, and looks like it works fine in
> > Tomcat 6.0.16, Geronimo 2.0.2, but it's failing in Websphere 6.1 with
> > the following exception. I'll try to debug later today, but just want
> > to mention here in case others might have seen this and have some
> > tips. I hope this is a configuration issue only. I also verified that
> > the same web-app from 1.1 release works ok.
> >
>
> Just to clarify, are you saying this works with the 1.1 release but not in
> the trunk code?
>

Yes

> I'd guess this will be due to differences with the base url and context path
> in WebSphere but haven't noticed any related changes since 1.1. Would also
> be interesting to see if ?wsdl returns wsdl containing the different port
> endpoints in the  different environments.
>

This was introduced by the revision #619602, where we check the
version of Servlet API in use, and if it's prior to 2.5, we use the
code below to retrieve the web app contextPath, and in WAS environment
we are not retrieving the proper application contextPath.

int version = context.getMajorVersion() * 100 +
context.getMinorVersion();
if (version >= 205) {

} else {
contextPath = config.getInitParameter("contextPath");
}


>...ant
>



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

Adding 'applicablePolicySets' to PolicySetAttachPoints

[Venkata Krishnan]

Hi,

Dealing with the 'appliesTo' attribute in PolicySets has been a subject that
I ended up discussing on the thread
http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg27768.html.  I
have gone forward with a suggestion that Sebastien sounded off on that
thread and have committed the changes under r620307.

First to set the stage
---
- The PolicySets could be defined in various definitions.xml which are all
read and aggreated for a domain
- Each PolicySet defines an 'appliesTo' attribute which is an xpath that
specifies the sca artifacts to which this policyset may apply.

The problem is about being able to validate the computed or calculated
policysets for a binding / implementation using this 'appliesTo' attribute.


Here is a summary of what's been done.
---
- In the contribution read phase, we postpone the reading of composite files
so that all definitions.xml file contents can all be aggregated
- After reading all other kinds of artifacts, we finally read the composite
files in the contribution.  The composite xml is first read as a xml
document and for each PolicySet defined for the domain we run the appliesTo
xpath against this xml document.  For the nodes returned as result of this
xpath evaluation, we add an attribute named 'applicablePolicySets' whose
value will be the name of the PolicySet in question.  So the read composite
will now be modified to include this attribute wherever applicable.
- The modified composite xml is then passed to the STaX processors for the
usual parsing and creation of the the assembly model objects.
- Then during the computing / calculation of PolicySets for a
PolicySetAttachPoint (i.e. a binding or an implementation) the matching
policysets are validated against the list that has been made in the
'applicablePolicySets' attribute of the PolicySetAttachPoint.

As a result of this our samples now don't define their own intents to target
specific policysets for specific references / services.  Instead this
targeting is achieved by the proper specification of the 'appliesTo'
attribute in the PolicySet.

Please let me know your thoughts on this.

Thanks

- Venkat

Re: REMINDER: Board Reports - DUE MONDAY

[Luciano Resende]

The reports are due tomorrow, it would be great if people could review
and update the draft available in our wiki.

[1] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Tuscany+Board+Report

On Feb 3, 2008 5:03 PM, Luciano Resende <[EMAIL PROTECTED]> wrote:
> It is that time again, let's start collaborating in Tuscany draft
> report in our wiki [1]
>
> [1] 
> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Tuscany+Board+Report
>
>
>
> -- Forwarded message --
> From: Noel J. Bergman <[EMAIL PROTECTED]>
> Date: Feb 3, 2008 4:47 PM
> Subject: REMINDER: Board Reports
> To: [EMAIL PROTECTED]
>
>
> It is that time again, i.e., the beginning of a new month.  Time to start
> preparing reports for the Board.
>
> --- Noel
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
>
> --
> Luciano Resende
> Apache Tuscany Committer
> http://people.apache.org/~lresende
> http://lresende.blogspot.com/
>



-- 
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: Tuscany 1.1 in maven repo

[Dave Sowerby]

Hey Simon,

All looks fine - artifacts are coming down as expected

Thanks :)

Dave.

On Feb 10, 2008 12:45 PM, Simon Laws <[EMAIL PROTECTED]> wrote:
>
> On Feb 8, 2008 4:31 PM, Simon Laws <[EMAIL PROTECTED]> wrote:
>
> >
> >
> > On Feb 8, 2008 4:27 PM, Dave Sowerby <[EMAIL PROTECTED]> wrote:
> >
> > > Hi All,
> > >
> > > I can't seem to spot the 1.1 artifacts over at
> > > http://people.apache.org/repo/m2-incubating-repository
> > >
> > > Is this intentional - has the repo location changed?  Or has it just
> > > slipped through the net?
> > >
> > > Cheers,
> > >
> > > Dave.
> > >
> > > --
> > > Dave Sowerby MEng MBCS
> > >
> > > -
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > > Oops, slipped through the net. Let me go sort that.
> >
> > Thanks
> >
> > Simon
> >
> Ok, Dave, Can you give it another spin to make sure I have everything the
> the right place.
>
> Thanks
>
> Simon
>



-- 
Dave Sowerby MEng MBCS

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

Re: XPath related question

[Venkata Krishnan]

Hi Doug and Raymond,

Thank you very much.  I just figured these out.  I am now using the prefixes
in all the xpaths I am using.

For the other question, I suppose specifying the return type as NODESET
returns a list of matching nodes.

- Venkat

On Feb 8, 2008 10:30 PM, Raymond Feng <[EMAIL PROTECTED]> wrote:

> Hi,
>
> My experience is that you need to set the NamespaceContext on the XPath so
> that you can map a prefix to the namespace URI. See:
>
> http://java.sun.com/j2se/1.5.0/docs/api/javax/xml/xpath/XPath.html#setNamespaceContext(javax.xml.namespace.NamespaceContext)
> .
>
> For example, you can associate "sca" or "s" (maybe even an empty one) with
> the SCA namespace. Then you can use the prefix with the XPath expression,
> such as s:composite or sca:composite.
>
> Thanks,
> Raymond
>
> - Original Message -
> From: "Venkata Krishnan" <[EMAIL PROTECTED]>
> To: "tuscany-dev" 
> Sent: Friday, February 08, 2008 4:22 AM
> Subject: XPath related question
>
>
> > Hi,
> >
> > I am trying to get some xpaths evaluated against a composite file.  I
> have
> > a
> > couple of questions related to xpath queries.  Can somebody familiar
> > please
> > help.   Thanks.
> >
> > My composite element in the composite file defines the defaultnamespace
> -
> > xmlns="http://www.osoa.org/xmlns/sca/1.0";.  Given this if I construct a
> > xpath that is like "/composite" or "/composite/component" the query does
> > not
> > return any result.
> >
> > On the other hand if I added the following namespace declaration to the
> > composite element "xmlns*:sca*="http://www.osoa.org/xmlns/sca/1.0"; and
> > then
> > constructed an xpath - "/sca:composite" or
> "/sca:composite/sca:component",
> > then the query returns the expected results.  Any clues to what I am
> > missing
> > out here ?
> >
> > The other question I have is, to an xpath -
> "/sca:composite/sca:component"
> > I
> > expect the set of all component nodes to be returned, but instead I seem
> > to
> > be getting just the first one.  How do I get the set of all component
> > nodes
> > ?
> >
> > Thanks
> >
> > - Venkat
> >
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Performance results.

[Giorgio Zoppi]

I've tried my app a while ago in a 16 node-cluster and I'm publishing
my result at http://www.cli.di.unipi.it/~zoppi/out/ch06.html
They are in italian but you can find many images. I suppose to cache
component uri
as you can see in the code:
http://www.cli.di.unipi.it/~zoppi/out/apas06.html#d4e1968
in order to speed up applications.
At the end of this work there's all code that i crafted in order to
have a behavioural skeleton
task farm: a SCA distributed task executor.
Next I have to port it to the new Tuscany 1.1.
Cheers,
Giorgio

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

Re: Tuscany 1.1 in maven repo

[Simon Laws]

On Feb 8, 2008 4:31 PM, Simon Laws <[EMAIL PROTECTED]> wrote:

>
>
> On Feb 8, 2008 4:27 PM, Dave Sowerby <[EMAIL PROTECTED]> wrote:
>
> > Hi All,
> >
> > I can't seem to spot the 1.1 artifacts over at
> > http://people.apache.org/repo/m2-incubating-repository
> >
> > Is this intentional - has the repo location changed?  Or has it just
> > slipped through the net?
> >
> > Cheers,
> >
> > Dave.
> >
> > --
> > Dave Sowerby MEng MBCS
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> > Oops, slipped through the net. Let me go sort that.
>
> Thanks
>
> Simon
>
Ok, Dave, Can you give it another spin to make sure I have everything the
the right place.

Thanks

Simon