NoSuchMethodError: javax/wsdl/Operation
Trying to run Tuscany WebApp samples in WebSphere i get a NoSuchMethodError: javax/wsdl/Operation.getExtensibilityElements()Ljava/util/List. Anyone know how to fix that? This is with the class loader set to Classes loaded with application class loader first. ...ant
Re: Distribution zips and what they contain, was: SCA runtimes
On Feb 10, 2008 10:06 PM, Simon Nash [EMAIL PROTECTED] wrote: snip But that's OK, if people don't like that split I can also live with a single big runtime distro. Over time, we will add more and more optional features and this will become more and more of a problem. IMO, it's bad enough now that we need to do something. We don't seem to be reaching much consensus on this and i wonder if its because we don't understand what each of our priorities are. There was an attempt to find that out over at http://apache.markmail.org/message/4wldk6zdjxaxz4kf but now here on this thread I'm a bit lost after the many weeks of discussion so could you say more about which aspect is bad enough now and maybe summarise the important aspects you'd like the distribution(s) to have? ...ant
Re: JIRA backlog
On Feb 6, 2008 1:36 PM, ant elder [EMAIL PROTECTED] wrote: We've about 170 open JIRAs for SCA, (currently split over 3 versions but i'll go move all the SCA ones to SCA-next), what shall we do about them? There's various suggestions for how to improve JIRA handling listed at: http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Graduation+Next+Steps , which of those should we do? How about as a start we just all focus on JIRAs for a bit trying to resolve which ever ones we can to see if that brings the number down much? Thats what i'll go do for now ... ...ant Buried deep in [1] there was a suggestion that the next release will be called 1.2. I've created a 1.2 release label so we can use that to associate JIRA with the next release that we have either completed, or would like to see completed. Simon [1] http://apache.markmail.org/message/jwt6vnb3tc4xgfe5
Re: NoSuchMethodError: javax/wsdl/Operation
Exactly what i was looking for, thanks! ...ant On Feb 11, 2008 1:43 PM, Dave Sowerby [EMAIL PROTECTED] wrote: There are some instructions that work for me at: http://www.jetbrains.com/idea/documentation/howto_02.html The section called Configuring WebSphere Application Server Hope that helps :) Dave. On Feb 11, 2008 12:51 PM, ant elder [EMAIL PROTECTED] wrote: And another follow up question - anyone know how to get WebSphere to start up listening for a remote debugger to attach to it? ...ant On Feb 11, 2008 8:57 AM, Venkata Krishnan [EMAIL PROTECTED] wrote: Yes. Its the same with me as well. I have installed WAS 6.1 ND. Is there a particular fixpack that is to take care of this ? Thanks - Venkat On Feb 11, 2008 2:22 PM, ant elder [EMAIL PROTECTED] wrote: Trying to run Tuscany WebApp samples in WebSphere i get a NoSuchMethodError: javax/wsdl/Operation.getExtensibilityElements()Ljava/util/List. Anyone know how to fix that? This is with the class loader set to Classes loaded with application class loader first. ...ant -- Dave Sowerby MEng MBCS
Re: Tuscany: Axis2 codegen bug? - java interface exposed as service, annoted with javax.xml.ws.RequestWrapper(...) is not honoring the namespace
Clemens Utschig - Utschig wrote: 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? Yes, it would help. It might not solve all the problems, but it should get you further. I couldn't find a sample that uses interface.wsdl on a reference (seems like an omission), though there are a few that use it on a service definition. You would need to replace the interface.java element with something like interface.wsdl interface=http://model/common/serviceinterface#wsdl.interface(EmpFlexFieldService) / The generated wsdl file needs to be somewhere on your classpath. In our samples and tests that use generated wsdl, we put the wsdl files in the src/main/resources/wsdl directory. Simon 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 ?xml version=1.0 encoding=UTF-8? composite xmlns=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/; component name=FlexEmployeeServiceComponent implementation.java class=com.oracle.soa.test.tuscany.impl.EmployeeServiceComponent/ reference name=empFlexFieldService/ /component reference name=empFlexFieldService promote=FlexEmployeeServiceComponent/empFlexFieldService interface.java interface=model.common.serviceinterface.EmpFlexFieldService/ binding.ws uri=http://localhost:1234/Application4710-Model-context-root/EmpFlexFieldService/ /reference /composite 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 ?xml version='1.0' encoding='UTF-8'? soapenv:Envelope xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/; soapenv:Body _ns_:getEmployees1 xmlns:_ns_=/model/common/ empno xmlns=/model/common/1/empno /_ns_:getEmployees1 /soapenv:Body /soapenv:Envelope instead of soap:Envelope xmlns:soap=http://schemas.xmlsoap.org/soap/envelope/; soap:Body xmlns:ns1=/model/common/types/ ns1:getEmployees1 ns1:empno/ns1:empno /ns1:getEmployees1 /soap:Body /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
[jira] Updated: (TUSCANY-2042) Dynamically generated WSDL not generating output message for void types
[
https://issues.apache.org/jira/browse/TUSCANY-2042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lou Amodeo updated TUSCANY-2042:
Attachment: helloworld-ws-asynch.jar
Dynamically generated WSDL not generating output message for void types
-
Key: TUSCANY-2042
URL: https://issues.apache.org/jira/browse/TUSCANY-2042
Project: Tuscany
Issue Type: Bug
Reporter: Lou Amodeo
Attachments: helloworld-ws-asynch.jar
This problem is similar to Tuscany-1658 but it appears the fix is not working
properly in all cases. I am finding that the
namespace and element namespace values assigned durig the dynamic wsdl
definition generation are causing the following code to not function because
theif (element.getAttribute(targetNamespace).equals(namespaceURI)) {
is returning false. This is because the target namespace is being generated
as : targetNamespace=http://helloworld
while the element namespace is : http://helloworld/xsd
The method signature is : public void getGreetings(String name)
class: Java2WSDLHelper.java
private static void processNoArgAndVoidReturnMethods(Definition definition,
Class javaInterface) {
String namespaceURI = definition.getTargetNamespace();
String prefix = definition.getPrefix(namespaceURI);
String xsPrefix =
definition.getPrefix(http://www.w3.org/2001/XMLSchema;);
PortType portType =
(PortType)definition.getAllPortTypes().values().iterator().next();
Element schema = null;
Document document = null;
Types types = definition.getTypes();
if (types != null) {
for (Object ext : types.getExtensibilityElements()) {
if (ext instanceof Schema) {
Element element = ((Schema)ext).getElement();
if
(element.getAttribute(targetNamespace).equals(namespaceURI)) {
schema = element;
document = schema.getOwnerDocument();
break;
}
}
}
}
if (document == null) {
return;
}
Definition generated:
Definition: name=null targetNamespace=http://helloworld
Types:
SchemaExtensibilityElement ({http://www.w3.org/2001/XMLSchema}schema):
required=null
element=[xs:schema: null]
Message: name={http://helloworld}getGreetingsMessage
Part: name=part1
elementName={http://helloworld/xsd}getGreetings
PortType: name={http://helloworld}HelloWorldServicePortType
Operation: name=getGreetings
style=ONE_WAY,0
Input: name=null
Message: name={http://helloworld}getGreetingsMessage
Part: name=part1
elementName={http://helloworld/xsd}getGreetings
Binding: name={http://helloworld}HelloWorldServiceSOAP12Binding
PortType: name={http://helloworld}HelloWorldServicePortType
Operation: name=getGreetings
style=ONE_WAY,0
Input: name=null
Message: name={http://helloworld}getGreetingsMessage
Part: name=part1
elementName={http://helloworld/xsd}getGreetings
BindingOperation: name=getGreetings
BindingInput: name=null
SOAPBody ({http://schemas.xmlsoap.org/wsdl/soap12/}body):
required=null
use=literal
namespaceURI=http://helloworld
SOAPOperation ({http://schemas.xmlsoap.org/wsdl/soap12/}operation):
required=null
soapActionURI=urn:getGreetings
style=document
SOAPBinding ({http://schemas.xmlsoap.org/wsdl/soap12/}binding):
required=null
transportURI=http://schemas.xmlsoap.org/soap/http
style=document
Binding: name={http://helloworld}HelloWorldServiceSOAP11Binding
PortType: name={http://helloworld}HelloWorldServicePortType
Operation: name=getGreetings
style=ONE_WAY,0
Input: name=null
Message: name={http://helloworld}getGreetingsMessage
Part: name=part1
elementName={http://helloworld/xsd}getGreetings
BindingOperation: name=getGreetings
BindingInput: name=null
SOAPBody ({http://schemas.xmlsoap.org/wsdl/soap/}body):
required=null
use=literal
namespaceURI=http://helloworld
SOAPOperation ({http://schemas.xmlsoap.org/wsdl/soap/}operation):
required=null
soapActionURI=urn:getGreetings
style=document
SOAPBinding ({http://schemas.xmlsoap.org/wsdl/soap/}binding):
required=null
transportURI=http://schemas.xmlsoap.org/soap/http
style=document
Service: name={http://helloworld}HelloWorldService
Port: name=HelloWorldServiceSOAP11port
Binding: name={http://helloworld}HelloWorldServiceSOAP11Binding
PortType: name={http://helloworld}HelloWorldServicePortType
Operation: name=getGreetings
style=ONE_WAY,0
Input: name=null
Message: name={http://helloworld}getGreetingsMessage
Part: name=part1
elementName={http://helloworld/xsd}getGreetings
BindingOperation: name=getGreetings
BindingInput: name=null
SOAPBody ({http://schemas.xmlsoap.org/wsdl/soap/}body):
[jira] Created: (TUSCANY-2042) Dynamically generated WSDL not generating output message for void types
Dynamically generated WSDL not generating output message for void types
-
Key: TUSCANY-2042
URL: https://issues.apache.org/jira/browse/TUSCANY-2042
Project: Tuscany
Issue Type: Bug
Reporter: Lou Amodeo
This problem is similar to Tuscany-1658 but it appears the fix is not working
properly in all cases. I am finding that the
namespace and element namespace values assigned durig the dynamic wsdl
definition generation are causing the following code to not function because
theif (element.getAttribute(targetNamespace).equals(namespaceURI)) {
is returning false. This is because the target namespace is being generated
as : targetNamespace=http://helloworld
while the element namespace is : http://helloworld/xsd
The method signature is : public void getGreetings(String name)
class: Java2WSDLHelper.java
private static void processNoArgAndVoidReturnMethods(Definition definition,
Class javaInterface) {
String namespaceURI = definition.getTargetNamespace();
String prefix = definition.getPrefix(namespaceURI);
String xsPrefix =
definition.getPrefix(http://www.w3.org/2001/XMLSchema;);
PortType portType =
(PortType)definition.getAllPortTypes().values().iterator().next();
Element schema = null;
Document document = null;
Types types = definition.getTypes();
if (types != null) {
for (Object ext : types.getExtensibilityElements()) {
if (ext instanceof Schema) {
Element element = ((Schema)ext).getElement();
if
(element.getAttribute(targetNamespace).equals(namespaceURI)) {
schema = element;
document = schema.getOwnerDocument();
break;
}
}
}
}
if (document == null) {
return;
}
Definition generated:
Definition: name=null targetNamespace=http://helloworld
Types:
SchemaExtensibilityElement ({http://www.w3.org/2001/XMLSchema}schema):
required=null
element=[xs:schema: null]
Message: name={http://helloworld}getGreetingsMessage
Part: name=part1
elementName={http://helloworld/xsd}getGreetings
PortType: name={http://helloworld}HelloWorldServicePortType
Operation: name=getGreetings
style=ONE_WAY,0
Input: name=null
Message: name={http://helloworld}getGreetingsMessage
Part: name=part1
elementName={http://helloworld/xsd}getGreetings
Binding: name={http://helloworld}HelloWorldServiceSOAP12Binding
PortType: name={http://helloworld}HelloWorldServicePortType
Operation: name=getGreetings
style=ONE_WAY,0
Input: name=null
Message: name={http://helloworld}getGreetingsMessage
Part: name=part1
elementName={http://helloworld/xsd}getGreetings
BindingOperation: name=getGreetings
BindingInput: name=null
SOAPBody ({http://schemas.xmlsoap.org/wsdl/soap12/}body):
required=null
use=literal
namespaceURI=http://helloworld
SOAPOperation ({http://schemas.xmlsoap.org/wsdl/soap12/}operation):
required=null
soapActionURI=urn:getGreetings
style=document
SOAPBinding ({http://schemas.xmlsoap.org/wsdl/soap12/}binding):
required=null
transportURI=http://schemas.xmlsoap.org/soap/http
style=document
Binding: name={http://helloworld}HelloWorldServiceSOAP11Binding
PortType: name={http://helloworld}HelloWorldServicePortType
Operation: name=getGreetings
style=ONE_WAY,0
Input: name=null
Message: name={http://helloworld}getGreetingsMessage
Part: name=part1
elementName={http://helloworld/xsd}getGreetings
BindingOperation: name=getGreetings
BindingInput: name=null
SOAPBody ({http://schemas.xmlsoap.org/wsdl/soap/}body):
required=null
use=literal
namespaceURI=http://helloworld
SOAPOperation ({http://schemas.xmlsoap.org/wsdl/soap/}operation):
required=null
soapActionURI=urn:getGreetings
style=document
SOAPBinding ({http://schemas.xmlsoap.org/wsdl/soap/}binding):
required=null
transportURI=http://schemas.xmlsoap.org/soap/http
style=document
Service: name={http://helloworld}HelloWorldService
Port: name=HelloWorldServiceSOAP11port
Binding: name={http://helloworld}HelloWorldServiceSOAP11Binding
PortType: name={http://helloworld}HelloWorldServicePortType
Operation: name=getGreetings
style=ONE_WAY,0
Input: name=null
Message: name={http://helloworld}getGreetingsMessage
Part: name=part1
elementName={http://helloworld/xsd}getGreetings
BindingOperation: name=getGreetings
BindingInput: name=null
SOAPBody ({http://schemas.xmlsoap.org/wsdl/soap/}body):
required=null
use=literal
namespaceURI=http://helloworld
SOAPOperation ({http://schemas.xmlsoap.org/wsdl/soap/}operation):
required=null
soapActionURI=urn:getGreetings
style=document
SOAPBinding ({http://schemas.xmlsoap.org/wsdl/soap/}binding):
required=null
transportURI=http://schemas.xmlsoap.org/soap/http
style=document
SOAPAddress ({http://schemas.xmlsoap.org/wsdl/soap/}address):
[jira] Commented: (TUSCANY-2042) Dynamically generated WSDL not generating output message for void types
[
https://issues.apache.org/jira/browse/TUSCANY-2042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12567848#action_12567848
]
Scott Kurz commented on TUSCANY-2042:
-
It is looking more like an Axis2 versioning issue for me.
In 1.3, Axis2 J2W seems to switch from generating:
* wsdl def TNS=xxx
* schema TNS for wrapper elems = xxx/xsd
like it did in Axis2 1.2,
to simply:
* wsdl def TNS=xxx
* schema TNS for wrapper elems = xxx
which looks to be my issue.
Dynamically generated WSDL not generating output message for void types
-
Key: TUSCANY-2042
URL: https://issues.apache.org/jira/browse/TUSCANY-2042
Project: Tuscany
Issue Type: Bug
Reporter: Lou Amodeo
Fix For: Java-SCA-Next
Attachments: helloworld-ws-asynch.jar
This problem is similar to Tuscany-1658 but it appears the fix is not working
properly in all cases. I am finding that the
namespace and element namespace values assigned durig the dynamic wsdl
definition generation are causing the following code to not function because
theif (element.getAttribute(targetNamespace).equals(namespaceURI)) {
is returning false. This is because the target namespace is being generated
as : targetNamespace=http://helloworld
while the element namespace is : http://helloworld/xsd
The method signature is : public void getGreetings(String name)
class: Java2WSDLHelper.java
private static void processNoArgAndVoidReturnMethods(Definition definition,
Class javaInterface) {
String namespaceURI = definition.getTargetNamespace();
String prefix = definition.getPrefix(namespaceURI);
String xsPrefix =
definition.getPrefix(http://www.w3.org/2001/XMLSchema;);
PortType portType =
(PortType)definition.getAllPortTypes().values().iterator().next();
Element schema = null;
Document document = null;
Types types = definition.getTypes();
if (types != null) {
for (Object ext : types.getExtensibilityElements()) {
if (ext instanceof Schema) {
Element element = ((Schema)ext).getElement();
if
(element.getAttribute(targetNamespace).equals(namespaceURI)) {
schema = element;
document = schema.getOwnerDocument();
break;
}
}
}
}
if (document == null) {
return;
}
Definition generated:
Definition: name=null targetNamespace=http://helloworld
Types:
SchemaExtensibilityElement ({http://www.w3.org/2001/XMLSchema}schema):
required=null
element=[xs:schema: null]
Message: name={http://helloworld}getGreetingsMessage
Part: name=part1
elementName={http://helloworld/xsd}getGreetings
PortType: name={http://helloworld}HelloWorldServicePortType
Operation: name=getGreetings
style=ONE_WAY,0
Input: name=null
Message: name={http://helloworld}getGreetingsMessage
Part: name=part1
elementName={http://helloworld/xsd}getGreetings
Binding: name={http://helloworld}HelloWorldServiceSOAP12Binding
PortType: name={http://helloworld}HelloWorldServicePortType
Operation: name=getGreetings
style=ONE_WAY,0
Input: name=null
Message: name={http://helloworld}getGreetingsMessage
Part: name=part1
elementName={http://helloworld/xsd}getGreetings
BindingOperation: name=getGreetings
BindingInput: name=null
SOAPBody ({http://schemas.xmlsoap.org/wsdl/soap12/}body):
required=null
use=literal
namespaceURI=http://helloworld
SOAPOperation ({http://schemas.xmlsoap.org/wsdl/soap12/}operation):
required=null
soapActionURI=urn:getGreetings
style=document
SOAPBinding ({http://schemas.xmlsoap.org/wsdl/soap12/}binding):
required=null
transportURI=http://schemas.xmlsoap.org/soap/http
style=document
Binding: name={http://helloworld}HelloWorldServiceSOAP11Binding
PortType: name={http://helloworld}HelloWorldServicePortType
Operation: name=getGreetings
style=ONE_WAY,0
Input: name=null
Message: name={http://helloworld}getGreetingsMessage
Part: name=part1
elementName={http://helloworld/xsd}getGreetings
BindingOperation: name=getGreetings
BindingInput: name=null
SOAPBody ({http://schemas.xmlsoap.org/wsdl/soap/}body):
required=null
use=literal
namespaceURI=http://helloworld
SOAPOperation ({http://schemas.xmlsoap.org/wsdl/soap/}operation):
required=null
soapActionURI=urn:getGreetings
style=document
SOAPBinding ({http://schemas.xmlsoap.org/wsdl/soap/}binding):
required=null
transportURI=http://schemas.xmlsoap.org/soap/http
style=document
Service: name={http://helloworld}HelloWorldService
Port: name=HelloWorldServiceSOAP11port
Binding: name={http://helloworld}HelloWorldServiceSOAP11Binding
PortType:
Re: svn commit: r620376 - /incubator/tuscany/java/sca/modules/host-webapp/src/main/java/org/apache/tuscany/sca/host/webapp/WebAppServletHost.java
Hi,
I just tested the WAR with Jetty-5.1.14 and Tomcat-5.5.26. It was broken
with Jetty-5.1.14 as the getContextPth() method is not available. On
Tomcat-5.5.26, the implementation class of ServletContext happens to have
the method and it's by luck working.
Thanks,
Raymond
- Original Message -
From: Raymond Feng [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Sunday, February 10, 2008 9:46 PM
Subject: Re: svn commit: r620376 -
/incubator/tuscany/java/sca/modules/host-webapp/src/main/java/org/apache/tuscany/sca/host/webapp/WebAppServletHost.java
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=620376view=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=620376r1=620375r2=620376view=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]
Spring Integration Tests
I noticed there are no spring-related tests in the sca/itest folder and I would like to volunteer to add a few. Does this sound like a good idea? I would probably need some help setting up the basic structure before adding content. Thanks, --Kevin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tuscany with Weblogic
Yup, all worked great :) Dave. On Feb 11, 2008 5:30 PM, Luciano Resende [EMAIL PROTECTED] wrote: Thanks, great post. Were you able to run calculator-ws-webapp sample as well ? On Feb 11, 2008 9:10 AM, Dave Sowerby [EMAIL PROTECTED] wrote: All, I've spotted there's no FAQs for using Tuscany with Weblogic, so I thought I'd throw something together to help :) Over on my blog: http://davesowerby.blogspot.com/2008/02/using-tuscany-with-weblogic.html It covers the updates necessary to webapps and then an example of how to deploy. If you think it'll be useful, please feel free to link from the FAQs Cheers, Dave. -- Dave Sowerby MEng MBCS - 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/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Dave Sowerby MEng MBCS - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tuscany with Weblogic
Thanks, great post. Were you able to run calculator-ws-webapp sample as well ? On Feb 11, 2008 9:10 AM, Dave Sowerby [EMAIL PROTECTED] wrote: All, I've spotted there's no FAQs for using Tuscany with Weblogic, so I thought I'd throw something together to help :) Over on my blog: http://davesowerby.blogspot.com/2008/02/using-tuscany-with-weblogic.html It covers the updates necessary to webapps and then an example of how to deploy. If you think it'll be useful, please feel free to link from the FAQs Cheers, Dave. -- Dave Sowerby MEng MBCS - 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/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tuscany with Weblogic
All, I've spotted there's no FAQs for using Tuscany with Weblogic, so I thought I'd throw something together to help :) Over on my blog: http://davesowerby.blogspot.com/2008/02/using-tuscany-with-weblogic.html It covers the updates necessary to webapps and then an example of how to deploy. If you think it'll be useful, please feel free to link from the FAQs Cheers, Dave. -- Dave Sowerby MEng MBCS - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: NoSuchMethodError: javax/wsdl/Operation
I have been using WAS installed with the Application Server option. It needs a fix for a bug with Servlet Filters, that is available with FixPack 9 (or later I guess), and this fix need to be activated in the WAS admin console, navigate to Application Servers - server1 - Web Container - Customer Properties and configure a com.ibm.ws.webcontainer.invokefilterscompatibility property to true. Then, every time you deploy an Tuscany application, you should set the proper class path options : ¨Classes loaded with application class loader first and Single class loader per application. See also Sebastien's post [1] with much more details on this subject. Please let me know if this helps. [1] http://jsdelfino.blogspot.com/2007/10/how-to-use-apache-tuscany-with.html On Feb 11, 2008 12:57 AM, Venkata Krishnan [EMAIL PROTECTED] wrote: Yes. Its the same with me as well. I have installed WAS 6.1 ND. Is there a particular fixpack that is to take care of this ? Thanks - Venkat On Feb 11, 2008 2:22 PM, ant elder [EMAIL PROTECTED] wrote: Trying to run Tuscany WebApp samples in WebSphere i get a NoSuchMethodError: javax/wsdl/Operation.getExtensibilityElements()Ljava/util/List. Anyone know how to fix that? This is with the class loader set to Classes loaded with application class loader first. ...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]
RE: Tuscany: Axis2 codegen bug? - java interface exposed as service, annoted with javax.xml.ws.RequestWrapper(...) is not honoring the namespace
Also how is the mapping from ns to wsdl done w/o an include? /clemens (powered by ocs mobile) clemens utschig - utschig soa product management -Original Message- From: Clemens Utschig - Utschig [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org tuscany-dev@ws.apache.org Sent: 2/11/08 7:30 AM Subject: RE: Tuscany: Axis2 codegen bug? - java interface exposed as service, annoted with javax.xml.ws.RequestWrapper(...) is not honoring the namespace shouldn't an include do it, so that I could potentially store the wsdl anywhere .. I'll try that later today - thx for the advise.. -Original Message- From: Simon Nash [mailto:[EMAIL PROTECTED] Sent: Monday, February 11, 2008 5:54 AM 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 Clemens Utschig - Utschig wrote: 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? Yes, it would help. It might not solve all the problems, but it should get you further. I couldn't find a sample that uses interface.wsdl on a reference (seems like an omission), though there are a few that use it on a service definition. You would need to replace the interface.java element with something like interface.wsdl interface=http://model/common/serviceinterface#wsdl.interface(EmpFlexFieldService) / The generated wsdl file needs to be somewhere on your classpath. In our samples and tests that use generated wsdl, we put the wsdl files in the src/main/resources/wsdl directory. Simon 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 ?xml version=1.0 encoding=UTF-8? composite xmlns=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/; component name=FlexEmployeeServiceComponent implementation.java class=com.oracle.soa.test.tuscany.impl.EmployeeServiceComponent/ reference name=empFlexFieldService/ /component reference name=empFlexFieldService promote=FlexEmployeeServiceComponent/empFlexFieldService interface.java interface=model.common.serviceinterface.EmpFlexFieldService/ binding.ws uri=http://localhost:1234/Application4710-Model-context-root/EmpFlexFieldService/ /reference /composite 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 ?xml version='1.0' encoding='UTF-8'? soapenv:Envelope xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/; soapenv:Body _ns_:getEmployees1 xmlns:_ns_=/model/common/ empno xmlns=/model/common/1/empno /_ns_:getEmployees1 /soapenv:Body /soapenv:Envelope instead of soap:Envelope xmlns:soap=http://schemas.xmlsoap.org/soap/envelope/; soap:Body xmlns:ns1=/model/common/types/ ns1:getEmployees1 ns1:empno/ns1:empno /ns1:getEmployees1 /soap:Body /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
Re: Performance results.
2008/2/11, Simon Laws [EMAIL PROTECTED]: On Feb 10, 2008 12:50 PM, Giorgio Zoppi [EMAIL PROTECTED] wrote: 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.htmlhttp://www.cli.di.unipi.it/%7Ezoppi/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#d4e1968http://www.cli.di.unipi.it/%7Ezoppi/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] Hi Giorgio, thanks for posting the results. Looking at the graphs you can see the measured completion time diverging from the ideal completion time as the task size shrinks and the number of nodes increases. This is to be expected as the infrastructure becomes more noticeable in these situations. Yes it's expected because your infrastructure use a ConcurrentHashMap for async invocations as a Work queue. The question is is it too intrusive and do you have a feeling for where we get the best payback in reducing the overhead. You mention caching the URL. Yes. As you can see the grain is middle/coarse and if you dont' cache the URL, the situation get worse. I cache the url and I cache the callableReference, which i resolve for calling back. CallableReference -- proxy costs around 500ms too much for me. In other discussions over the last few weeks [1] [2] we are looking at a slightly simplified approach to deploying the nodes where the topology is calculated ahead of time and hence endpoint information can be provided with deployed composites. Rather than the nodes having to make calls across the information to find this information. This is initially less dynamic than the situation we have now but you could argue that it is more predictable. Do you see problems for you application in taking this slightly more static approach? No idea. I'll start to review all next week. I still have the previous code you attached to the open JIRA [3] sitting on my machine. My intention was to check it in as a demonstration but haven't done so yet. Should I wait until you have ported to 1.1? Yes. Wait, because i'm going to refactor inorder to have something more loosely decoupled. I saw the latest callback issue, so maybe i'll able to use infrastructure callback better. Cheers, Giorgio. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-2043) documentBaseURI is null when multiple wsdls in contribution with same namespace
documentBaseURI is null when multiple wsdls in contribution with same namespace -- Key: TUSCANY-2043 URL: https://issues.apache.org/jira/browse/TUSCANY-2043 Project: Tuscany Issue Type: Bug Reporter: Lou Amodeo I have a case where there are 2 wsdl files in the contribution with the same namespace. After the WSDL resolution the documentBaseURI attribute of the wsdl's DefinitionImpl is null. The is normally completed in the WebServiceBindingProcessor.resolve(). In this particular case there are 2 binding.ws elements in the contribution. One for the service and one for its callback binding. If I change the TNS of one of the WSDL files then the documnetBaseURI is filled in during the WebServiceBindingProcessor.resolve. So it appears there is in issue in the WSDL Model resolver when it finds multiple WSDL files with the same TNS. -- 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] Commented: (TUSCANY-1293) SDO does not work with OSGi
[
https://issues.apache.org/jira/browse/TUSCANY-1293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12567667#action_12567667
]
Kelvin Goodson commented on TUSCANY-1293:
-
Rajini,
sorry to take so long to get to this, and thanks for the patch. I'm working
towards getting thsi in for the next release. I note a couple of occasions in
the tests where an exception is caught, and then either output is made to the
System.out, or the exception is ignored. Could you help me understand if in
either of these cases the symptom is truly benign please? If so i will add a
comment to the code. If not then I'll change to let the exception surface
through the test infrastructure.
First is on OSGITestCase ...
// Start all the installed bundles
for (int i = 0; i bundles.size(); i++) {
Bundle bundle = (Bundle)bundles.get(i);
try {
bundle.start();
} catch (Exception e) {
e.printStackTrace();
System.out.println(Could not start bundle +
bundle);
}
}
second is in ClassLoaderTestCase (I think I can see this is benign, but could
do with confirmation)
for (int i = 0; i parentLoaders.length; i++) {
try {
return
parentLoaders[i].loadClass(className);
} catch (Exception e) {
}
}
SDO does not work with OSGi
---
Key: TUSCANY-1293
URL: https://issues.apache.org/jira/browse/TUSCANY-1293
Project: Tuscany
Issue Type: Bug
Components: Java SDO Implementation
Affects Versions: Java-SDO-beta1
Environment: OS X Eclipse 3.3 M7
Reporter: Bryan Hunt
Priority: Blocker
Fix For: Java-SDO-Next
Attachments: sdo-osgi.txt
When I execute:
XSDHelper.INSTANCE.define(schema, null);
I end up with a NullPointerException. I've tracked down root cause ...
The static initializer of the HelperProvider executes this code:
provider = getInstance(HelperProvider.class.getClassLoader());
which ends up calling:
HelperProvider provider = loadImplementation(cl, implName);
implName is null so
if (implName == null) {
implName = getImplementationName(cl);
}
ends up calling
implName = getImplementationName(cl);
which ends up calling:
InputStream is = cl.getResourceAsStream(SERVICE_RESOURCE_NAME);
where SERVICE_RESORUCE_NAME =
META-INF/services/commonj.sdo.impl.HelperProvider
getResourceAsStream() return null because META-INF/services does not exist in
the API bundle. It exists in the IMPL bundle and since you are using the
class loader from the API bundle, it won't work.
You can set
-Dcommonj.sdo.impl.HelperProvider=org.apache.tuscany.sdo.helper.HelperProviderImpl
to get around the above problem, but as soon as
return (HelperProvider) cl.loadClass(implName).newInstance();
executes, you get a CalssNotFoundException. Again, this is because you are
trying to load a class outside the bundle with the wrong class loader.
tried modifying the API manifest by hand to add
Eclipse-BuddyPolicy: dependent
and
Eclipse-BuddyPolicy: global
Either of those buddy policies will get past the class loader problem
(although I believe this is specific to eclipse and won't work for OSGi in
general), but when HelperProvider is initializing, you get the following
exception:
java.lang.ExceptionInInitializerError
at org.apache.tuscany.sdo.impl.AttributeImpl.clinit(AttributeImpl.java:126)
at
org.apache.tuscany.sdo.impl.SDOFactoryImpl.createAttribute(SDOFactoryImpl.java:239)
at org.apache.tuscany.sdo.impl.ClassImpl.clinit(ClassImpl.java:68)
at
org.apache.tuscany.sdo.impl.SDOFactoryImpl$SDOEcoreFactory.createEClass(SDOFactoryImpl.java:76)
at
org.apache.tuscany.sdo.impl.SDOPackageImpl.createEClass(SDOPackageImpl.java:622)
at
org.apache.tuscany.sdo.impl.SDOPackageImpl.createPackageContents(SDOPackageImpl.java:550)
at org.apache.tuscany.sdo.impl.SDOPackageImpl.init(SDOPackageImpl.java:259)
at org.apache.tuscany.sdo.SDOPackage.clinit(SDOPackage.java:76)
at sun.misc.Unsafe.ensureClassInitialized(Native Method)
at
sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:25)
at sun.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java:122)
at java.lang.reflect.Field.acquireFieldAccessor(Field.java:917)
at java.lang.reflect.Field.getFieldAccessor(Field.java:898)
at java.lang.reflect.Field.get(Field.java:357)
at
RE: Tuscany: Axis2 codegen bug? - java interface exposed as service, annoted with javax.xml.ws.RequestWrapper(...) is not honoring the namespace
shouldn't an include do it, so that I could potentially store the wsdl anywhere .. I'll try that later today - thx for the advise.. -Original Message- From: Simon Nash [mailto:[EMAIL PROTECTED] Sent: Monday, February 11, 2008 5:54 AM 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 Clemens Utschig - Utschig wrote: 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? Yes, it would help. It might not solve all the problems, but it should get you further. I couldn't find a sample that uses interface.wsdl on a reference (seems like an omission), though there are a few that use it on a service definition. You would need to replace the interface.java element with something like interface.wsdl interface=http://model/common/serviceinterface#wsdl.interface(EmpFlexFieldService) / The generated wsdl file needs to be somewhere on your classpath. In our samples and tests that use generated wsdl, we put the wsdl files in the src/main/resources/wsdl directory. Simon 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 ?xml version=1.0 encoding=UTF-8? composite xmlns=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/; component name=FlexEmployeeServiceComponent implementation.java class=com.oracle.soa.test.tuscany.impl.EmployeeServiceComponent/ reference name=empFlexFieldService/ /component reference name=empFlexFieldService promote=FlexEmployeeServiceComponent/empFlexFieldService interface.java interface=model.common.serviceinterface.EmpFlexFieldService/ binding.ws uri=http://localhost:1234/Application4710-Model-context-root/EmpFlexFieldService/ /reference /composite 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 ?xml version='1.0' encoding='UTF-8'? soapenv:Envelope xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/; soapenv:Body _ns_:getEmployees1 xmlns:_ns_=/model/common/ empno xmlns=/model/common/1/empno /_ns_:getEmployees1 /soapenv:Body /soapenv:Envelope instead of soap:Envelope xmlns:soap=http://schemas.xmlsoap.org/soap/envelope/; soap:Body xmlns:ns1=/model/common/types/ ns1:getEmployees1 ns1:empno/ns1:empno /ns1:getEmployees1 /soap:Body /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
Re: NoSuchMethodError: javax/wsdl/Operation
There are some instructions that work for me at: http://www.jetbrains.com/idea/documentation/howto_02.html The section called Configuring WebSphere Application Server Hope that helps :) Dave. On Feb 11, 2008 12:51 PM, ant elder [EMAIL PROTECTED] wrote: And another follow up question - anyone know how to get WebSphere to start up listening for a remote debugger to attach to it? ...ant On Feb 11, 2008 8:57 AM, Venkata Krishnan [EMAIL PROTECTED] wrote: Yes. Its the same with me as well. I have installed WAS 6.1 ND. Is there a particular fixpack that is to take care of this ? Thanks - Venkat On Feb 11, 2008 2:22 PM, ant elder [EMAIL PROTECTED] wrote: Trying to run Tuscany WebApp samples in WebSphere i get a NoSuchMethodError: javax/wsdl/Operation.getExtensibilityElements()Ljava/util/List. Anyone know how to fix that? This is with the class loader set to Classes loaded with application class loader first. ...ant -- Dave Sowerby MEng MBCS - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Spring Integration Tests
Hi Luciano, Good deal. I'll get started. It's been awhile since I've added to the project structure: directories, maven artifacts, etc. I'll let you know if I run into any trouble. Thanks, --Kevin On Feb 11, 2008 1:19 PM, Luciano Resende [EMAIL PROTECTED] wrote: Hey Kevin, sure, this would be welcomed. The sca/iTest are based on the jUnit framework. What kind of help would you need ? On Feb 11, 2008 10:31 AM, Kevin Williams [EMAIL PROTECTED] wrote: I noticed there are no spring-related tests in the sca/itest folder and I would like to volunteer to add a few. Does this sound like a good idea? I would probably need some help setting up the basic structure before adding content. Thanks, --Kevin - 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/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: NoSuchMethodError: javax/wsdl/Operation
ant elder wrote: Trying to run Tuscany WebApp samples in WebSphere i get a NoSuchMethodError: javax/wsdl/Operation.getExtensibilityElements()Ljava/util/List. Anyone know how to fix that? This is with the class loader set to Classes loaded with application class loader first. ...ant You need Single Class Loader as well. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Distribution zips and what they contain, was: SCA runtimes
ant elder wrote: On Feb 10, 2008 10:06 PM, Simon Nash [EMAIL PROTECTED] wrote: snip But that's OK, if people don't like that split I can also live with a single big runtime distro. Over time, we will add more and more optional features and this will become more and more of a problem. IMO, it's bad enough now that we need to do something. We don't seem to be reaching much consensus on this and i wonder if its because we don't understand what each of our priorities are. There was an attempt to find that out over at http://apache.markmail.org/message/4wldk6zdjxaxz4kf but now here on this thread I'm a bit lost after the many weeks of discussion so could you say more about which aspect is bad enough now and maybe summarise the important aspects you'd like the distribution(s) to have? ...ant From a user perspective, if the user is doing personal development, I suppose most users these days can put up with a 60MB download and a 60MB runtime. Where this becomes an issue is for people building applications or services that depend on the Tuscany runtime and need to be deployed into various environments. Examples are packaging the Tuscany runtime packaged inside a webapp, placing it in a shared library on a JEE appserver, placing it on the classpath in a J2SE environment, and maybe others. In all these cases, it's desirable for the deployed runtime to contain only what's needed to run the deployed applications. This is particularly important for Tuscany's external library dependencies, partly because of the number and diversity of these (read: risk), and partly because the versions of these libraries that we ship could potentially conflict with other things within the runtime environment. I also have a number of concerns from the Tuscany architecture, design and implementation perspective. As a Tuscany developer, I think the present situation is bad for the following reasons. 1. We claim to have a modular architecture but all evidence suggests that this isn't the case. For Tuscany SCA Java, we have to build it as one unit, test it as one unit, package it as one unit, and deliver it as one unit. Where is the modularity? What are the modules? 2. We know that there are dependency issues with some parts of the current codebase, with various parts of the runtime dragging dependencies that they shouldn't (either other parts of Tuscany or external libraries). How much of the Tuscany runtime, and how many external libraries, are needed to run a simple Hello World? How many of these things are we comfortable with having as dependencies, and how many do we think are a problem that should be eliminated? The present structure provides no answers to these questions. 3. We know that some of the maven modules are directly using implementation code within other maven modules rather than going through SPIs, but we don't know exactly what these non-SPI couplings are. Our claim to have a stable and well-defined SPI is a little shaky until we get a handle on these exception cases and address them. 4. To make Tuscany successful, we need a modular architecture and implementation that addresses all the above issues. This is because Tuscany needs to run in many different environments with many different configurations. Without modularity, we won't be able to do this. This doesn't necessarily mean that we need to split the distribution right now, but I think it does mean that we need to work on improving modularity in the code, in at least some of the ways listed above. This would give us and our users some flexibility to build and deploy different combinations of capability to meet their needs. Simon - 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 wrote: Thanks. I will ask Sebastien then :) I'm an administrator on project Tuscany but: - you are not in the Tuscany continuum group - I don't have seem to have authority to perform any user admin tasks Can you ask one of the continuum user administrators, here's the list: http://vmbuild.apache.org/continuum/security/userlist!show.action?roleName=User+Administrator -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Adding 'applicablePolicySets' to PolicySetAttachPoints
Venkata Krishnan wrote: 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 Looks good to me. I am assuming that 'applicablePolicySets' is a transient and calculated attribute used by Tuscany to flow policySet info with model elements across the composite reading phases, and not exposed to application developers. Were you able to leverage these changes to simplify the bigbank scenario? -- Jean-Sebastien - 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 wrote: shouldn't an include do it, so that I could potentially store the wsdl anywhere .. I'll try that later today - thx for the advise.. You don't even need an include, just place the WSDL file anywhere inside your SCA contribution (JAR or folder), reference its qualified name from your .composite and we should find it. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-2042) Dynamically generated WSDL not generating output message for void types
[
https://issues.apache.org/jira/browse/TUSCANY-2042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12567709#action_12567709
]
Scott Kurz commented on TUSCANY-2042:
-
I recreated this at the same time as stepping through the debugger.
I saw a problem here:
(not sure if it's the same as you
Dynamically generated WSDL not generating output message for void types
-
Key: TUSCANY-2042
URL: https://issues.apache.org/jira/browse/TUSCANY-2042
Project: Tuscany
Issue Type: Bug
Reporter: Lou Amodeo
Attachments: helloworld-ws-asynch.jar
This problem is similar to Tuscany-1658 but it appears the fix is not working
properly in all cases. I am finding that the
namespace and element namespace values assigned durig the dynamic wsdl
definition generation are causing the following code to not function because
theif (element.getAttribute(targetNamespace).equals(namespaceURI)) {
is returning false. This is because the target namespace is being generated
as : targetNamespace=http://helloworld
while the element namespace is : http://helloworld/xsd
The method signature is : public void getGreetings(String name)
class: Java2WSDLHelper.java
private static void processNoArgAndVoidReturnMethods(Definition definition,
Class javaInterface) {
String namespaceURI = definition.getTargetNamespace();
String prefix = definition.getPrefix(namespaceURI);
String xsPrefix =
definition.getPrefix(http://www.w3.org/2001/XMLSchema;);
PortType portType =
(PortType)definition.getAllPortTypes().values().iterator().next();
Element schema = null;
Document document = null;
Types types = definition.getTypes();
if (types != null) {
for (Object ext : types.getExtensibilityElements()) {
if (ext instanceof Schema) {
Element element = ((Schema)ext).getElement();
if
(element.getAttribute(targetNamespace).equals(namespaceURI)) {
schema = element;
document = schema.getOwnerDocument();
break;
}
}
}
}
if (document == null) {
return;
}
Definition generated:
Definition: name=null targetNamespace=http://helloworld
Types:
SchemaExtensibilityElement ({http://www.w3.org/2001/XMLSchema}schema):
required=null
element=[xs:schema: null]
Message: name={http://helloworld}getGreetingsMessage
Part: name=part1
elementName={http://helloworld/xsd}getGreetings
PortType: name={http://helloworld}HelloWorldServicePortType
Operation: name=getGreetings
style=ONE_WAY,0
Input: name=null
Message: name={http://helloworld}getGreetingsMessage
Part: name=part1
elementName={http://helloworld/xsd}getGreetings
Binding: name={http://helloworld}HelloWorldServiceSOAP12Binding
PortType: name={http://helloworld}HelloWorldServicePortType
Operation: name=getGreetings
style=ONE_WAY,0
Input: name=null
Message: name={http://helloworld}getGreetingsMessage
Part: name=part1
elementName={http://helloworld/xsd}getGreetings
BindingOperation: name=getGreetings
BindingInput: name=null
SOAPBody ({http://schemas.xmlsoap.org/wsdl/soap12/}body):
required=null
use=literal
namespaceURI=http://helloworld
SOAPOperation ({http://schemas.xmlsoap.org/wsdl/soap12/}operation):
required=null
soapActionURI=urn:getGreetings
style=document
SOAPBinding ({http://schemas.xmlsoap.org/wsdl/soap12/}binding):
required=null
transportURI=http://schemas.xmlsoap.org/soap/http
style=document
Binding: name={http://helloworld}HelloWorldServiceSOAP11Binding
PortType: name={http://helloworld}HelloWorldServicePortType
Operation: name=getGreetings
style=ONE_WAY,0
Input: name=null
Message: name={http://helloworld}getGreetingsMessage
Part: name=part1
elementName={http://helloworld/xsd}getGreetings
BindingOperation: name=getGreetings
BindingInput: name=null
SOAPBody ({http://schemas.xmlsoap.org/wsdl/soap/}body):
required=null
use=literal
namespaceURI=http://helloworld
SOAPOperation ({http://schemas.xmlsoap.org/wsdl/soap/}operation):
required=null
soapActionURI=urn:getGreetings
style=document
SOAPBinding ({http://schemas.xmlsoap.org/wsdl/soap/}binding):
required=null
transportURI=http://schemas.xmlsoap.org/soap/http
style=document
Service: name={http://helloworld}HelloWorldService
Port: name=HelloWorldServiceSOAP11port
Binding: name={http://helloworld}HelloWorldServiceSOAP11Binding
PortType: name={http://helloworld}HelloWorldServicePortType
Operation: name=getGreetings
style=ONE_WAY,0
Input: name=null
Message: name={http://helloworld}getGreetingsMessage
Part: name=part1
Re: NoSuchMethodError: javax/wsdl/Operation
There's two jars with WSDL4J relevant to the 6.1 appserver runtime: WAS\plugins\com.ibm.ws.runtime_6.1.0.jar WAS\plugins\org.apache.axis2_6.1.0.jar The rest are relevant for tooling and client envs. The first of those has some version WSDL4J 1.5 and the latter 1.6. So you manually patched wsdl4j 1.6.2 into com.ibm.ws.runtime_6.1.0.jar? On Feb 11, 2008 2:02 PM, ant elder [EMAIL PROTECTED] wrote: I have done all this and still see the problem. I've also search for all the wsdl4j jars in the WAS install and replaced the few i found with the 1.6.2jar and still see the problem, any other ideas? Seems odd that Venkat and I both hit this but others don't. ...ant On Feb 11, 2008 4:47 PM, Luciano Resende [EMAIL PROTECTED] wrote: I have been using WAS installed with the Application Server option. It needs a fix for a bug with Servlet Filters, that is available with FixPack 9 (or later I guess), and this fix need to be activated in the WAS admin console, navigate to Application Servers - server1 - Web Container - Customer Properties and configure a com.ibm.ws.webcontainer.invokefilterscompatibility property to true. Then, every time you deploy an Tuscany application, you should set the proper class path options : ¨Classes loaded with application class loader first and Single class loader per application. See also Sebastien's post [1] with much more details on this subject. Please let me know if this helps. [1] http://jsdelfino.blogspot.com/2007/10/how-to-use-apache-tuscany-with.html On Feb 11, 2008 12:57 AM, Venkata Krishnan [EMAIL PROTECTED] wrote: Yes. Its the same with me as well. I have installed WAS 6.1 ND. Is there a particular fixpack that is to take care of this ? Thanks - Venkat On Feb 11, 2008 2:22 PM, ant elder [EMAIL PROTECTED] wrote: Trying to run Tuscany WebApp samples in WebSphere i get a NoSuchMethodError: javax/wsdl/Operation.getExtensibilityElements()Ljava/util/List. Anyone know how to fix that? This is with the class loader set to Classes loaded with application class loader first. ...ant -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://people.apache.org/%7Elresende http://lresende.blogspot.com/ - 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: NoSuchMethodError: javax/wsdl/Operation
Ant, There is more than one version of WSDL4J in the WAS 6.1 image. You're probably getting the wrong one. Generally speaking WAS 6.1 uses OSGI bundle manifests and a special OSGi-enabled classloader network to load the right target class starting from a given source classloader. There are some OSGI settings which can help choose the right target.. however your source classloader is an app classloader, rather than another WAS runtime-level classloader, so I'm not sure myself how the OSGI settings can be used from an app classloader. Hope that helps, Scott On Feb 11, 2008 11:47 AM, Luciano Resende [EMAIL PROTECTED] wrote: I have been using WAS installed with the Application Server option. It needs a fix for a bug with Servlet Filters, that is available with FixPack 9 (or later I guess), and this fix need to be activated in the WAS admin console, navigate to Application Servers - server1 - Web Container - Customer Properties and configure a com.ibm.ws.webcontainer.invokefilterscompatibility property to true. Then, every time you deploy an Tuscany application, you should set the proper class path options : ¨Classes loaded with application class loader first and Single class loader per application. See also Sebastien's post [1] with much more details on this subject. Please let me know if this helps. [1] http://jsdelfino.blogspot.com/2007/10/how-to-use-apache-tuscany-with.html On Feb 11, 2008 12:57 AM, Venkata Krishnan [EMAIL PROTECTED] wrote: Yes. Its the same with me as well. I have installed WAS 6.1 ND. Is there a particular fixpack that is to take care of this ? Thanks - Venkat On Feb 11, 2008 2:22 PM, ant elder [EMAIL PROTECTED] wrote: Trying to run Tuscany WebApp samples in WebSphere i get a NoSuchMethodError: javax/wsdl/Operation.getExtensibilityElements()Ljava/util/List. Anyone know how to fix that? This is with the class loader set to Classes loaded with application class loader first. ...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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Performance results.
On Feb 10, 2008 12:50 PM, Giorgio Zoppi [EMAIL PROTECTED] wrote: 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.htmlhttp://www.cli.di.unipi.it/%7Ezoppi/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#d4e1968http://www.cli.di.unipi.it/%7Ezoppi/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] Hi Giorgio, thanks for posting the results. Looking at the graphs you can see the measured completion time diverging from the ideal completion time as the task size shrinks and the number of nodes increases. This is to be expected as the infrastructure becomes more noticeable in these situations. The question is is it too intrusive and do you have a feeling for where we get the best payback in reducing the overhead. You mention caching the URL. In other discussions over the last few weeks [1] [2] we are looking at a slightly simplified approach to deploying the nodes where the topology is calculated ahead of time and hence endpoint information can be provided with deployed composites. Rather than the nodes having to make calls across the information to find this information. This is initially less dynamic than the situation we have now but you could argue that it is more predictable. Do you see problems for you application in taking this slightly more static approach? I still have the previous code you attached to the open JIRA [3] sitting on my machine. My intention was to check it in as a demonstration but haven't done so yet. Should I wait until you have ported to 1.1? Regards Simon [1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg27362.html [2] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg27609.html [3] https://issues.apache.org/jira/browse/TUSCANY-1863
[jira] Created: (TUSCANY-2041) Repeated nill elements of extended type cause Parser found unknown element exception
Repeated nill elements of extended type cause Parser found unknown element exception -- Key: TUSCANY-2041 URL: https://issues.apache.org/jira/browse/TUSCANY-2041 Project: Tuscany Issue Type: Bug Components: C++ SDO Affects Versions: Cpp-Next Environment: XP SP2, VC7 Reporter: Simon Laws With the schema schema xmlns=http://www.w3.org/2001/XMLSchema; targetNamespace=http://www.example.org/AnnonTypes; xmlns:tns=http://www.example.org/AnnonTypes; elementFormDefault=qualified element name=Top complexType sequence element name=attribute nillable=true minOccurs=0 maxOccurs=unbounded complexType simpleContent extension base=string attribute name=name type=string use=required/ /extension /simpleContent /complexType /element /sequence /complexType /element /schema And XML tns:Top xmlns:tns=http://www.example.org/AnnonTypes; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://www.example.org/AnnonTypes AnnonTypes2.xsd tns:attribute name=ABC xsi:nil=true xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance/ !--tns:attribute name=DEF xsi:nil=true xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance/ tns:attribute name=GHI xsi:nil=true xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance/ tns:attribute name=JKL xsi:nil=true xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance-- /tns:Top When multiple attribute elements are present the following error is reported. SDO_DAS_XML_ParserException Object ( [message:protected] = SDO_DAS_XML::loadFile - Unable to parse the supplied xml file 1 parse error(s) occurred when parsing the file 'AnnonTypes2.xml': 1. Parser found unknown element attribute [string:private] = [code:protected] = 0 [file:protected] = C:\simon\php\workspace\php-branch\phpscripts\chrisdougla s\test.php [line:protected] = 52 [trace:private] = Array ( [0] = Array ( [file] = C:\simon\php\workspace\php-branch\phpscripts\chris douglas\test.php [line] = 52 [function] = loadFile [class] = SDO_DAS_XML [type] = - [args] = Array ( [0] = AnnonTypes2.xml ) ) ) [cause] = ) -- 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] Updated: (TUSCANY-257) recently added file Interface2JavaGenerator.java is not compatible with JDK 1.4
[ https://issues.apache.org/jira/browse/TUSCANY-257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amita Vadhavkar updated TUSCANY-257: Attachment: 257.patch have used Paul's work and created 257.patch. please review recently added file Interface2JavaGenerator.java is not compatible with JDK 1.4 --- Key: TUSCANY-257 URL: https://issues.apache.org/jira/browse/TUSCANY-257 Project: Tuscany Issue Type: Bug Components: Java SDO Tools Environment: all Reporter: Paul Golick Fix For: Java-SDO-Next Attachments: 257.patch, newFiles.jar, patchInterface2JavaGenerator.txt, patchUpdated.txt Interface2JavaGenerator.java uses java.lang.reflect.ParameterizedType and java.lang.reflect.Type that were added in Java 5 for generics. It appears that the portion of Interface2JavaGenerator that uses ParameterizedType and Type is not needed for Java 1.4 classes. -- 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: Adding 'applicablePolicySets' to PolicySetAttachPoints
Hi Venkat A question. snip... - In the contribution read phase, we postpone the reading of composite files so that all definitions.xml file contents can all be aggregated Do you mean all the definitions.xml files in the contribution or all the definitions.xml files in the domain? Simon
RE: Tuscany: Axis2 codegen bug? - java interface exposed as service, annoted with javax.xml.ws.RequestWrapper(...) is not honoring the namespace
Jean-sebastien, Qualified = target namespace?or wsdl name? Say my wsdl is named aaa.wsdl do I reference it by http://aaa ? Thx clemens -Original Message- From: Jean-Sebastien Delfino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: 2/11/08 6:33 PM Subject: Re: Tuscany: Axis2 codegen bug? - java interface exposed as service, annoted with javax.xml.ws.RequestWrapper(...) is not honoring the namespace Clemens Utschig - Utschig wrote: shouldn't an include do it, so that I could potentially store the wsdl anywhere .. I'll try that later today - thx for the advise.. You don't even need an include, just place the WSDL file anywhere inside your SCA contribution (JAR or folder), reference its qualified name from your .composite and we should find it. -- Jean-Sebastien - 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: Spring Integration Tests
Thanks. Any addition to the tests will be really helpful. To get a jumpstart you could copy over one of the existing tests and modify it deleting / adding classes and resources. - Venkat On Feb 12, 2008 12:01 AM, Kevin Williams [EMAIL PROTECTED] wrote: I noticed there are no spring-related tests in the sca/itest folder and I would like to volunteer to add a few. Does this sound like a good idea? I would probably need some help setting up the basic structure before adding content. Thanks, --Kevin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Spring Integration Tests
Hey Kevin, sure, this would be welcomed. The sca/iTest are based on the jUnit framework. What kind of help would you need ? On Feb 11, 2008 10:31 AM, Kevin Williams [EMAIL PROTECTED] wrote: I noticed there are no spring-related tests in the sca/itest folder and I would like to volunteer to add a few. Does this sound like a good idea? I would probably need some help setting up the basic structure before adding content. Thanks, --Kevin - 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/ - 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
Sorry for the break, I have committed an update fix that should take
care of the web container using old version of servlet api. I also
added code to throw an exception when we fail to get the proper
contextPath using the multiple methods we support.
On Feb 11, 2008 10:31 AM, Raymond Feng [EMAIL PROTECTED] wrote:
Hi,
I just tested the WAR with Jetty-5.1.14 and Tomcat-5.5.26. It was broken
with Jetty-5.1.14 as the getContextPth() method is not available. On
Tomcat-5.5.26, the implementation class of ServletContext happens to have
the method and it's by luck working.
Thanks,
Raymond
- Original Message -
From: Raymond Feng [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Sunday, February 10, 2008 9:46 PM
Subject: Re: svn commit: r620376 -
/incubator/tuscany/java/sca/modules/host-webapp/src/main/java/org/apache/tuscany/sca/host/webapp/WebAppServletHost.java
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=620376view=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=620376r1=620375r2=620376view=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]
--
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]
[jira] Commented: (TUSCANY-1689) XSD2JavaGenerator generates non-compilable FactoryImpl class with complexType named Descriptor
[
https://issues.apache.org/jira/browse/TUSCANY-1689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12567628#action_12567628
]
Ron Gavlin commented on TUSCANY-1689:
-
Added as Eclipse EMF Bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=218494
XSD2JavaGenerator generates non-compilable FactoryImpl class with complexType
named Descriptor
Key: TUSCANY-1689
URL: https://issues.apache.org/jira/browse/TUSCANY-1689
Project: Tuscany
Issue Type: Bug
Components: Java SDO Tools
Environment: Windows XP SP2 w/Sun JDK 1.4.2_11
Reporter: Ron Gavlin
Fix For: Java-SDO-Next
I have a schema with a complexType named Descriptor.
The generated FactoryImpl.java class includes the following code which does
not compile because the return type
org.eclipse.emf.ecore.EPackage.Descriptor is not compatible with
Factory.createDescriptor() with return type myNamespace.Descriptor:
public Descriptor createDescriptor()
{
DescriptorImpl descriptor = new DescriptorImpl();
return descriptor;
}
I suspect this is an EMF bug but I am reporting it here.
--
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: PolicyHanders
Hi Greg, Thanks for your observations / suggestions. Please see my comments inline. I apologize for making them lengthy in the hope that it would trigger more discussions. - Venkat On Feb 7, 2008 1:33 AM, Greg Dritschler [EMAIL PROTECTED] wrote: I have been looking at the PolicyHandler support for Java implementations and overall I like the direction this is going. I have some comments about it. 1. If a given component/operation has multiple policy sets that are handled by the same PolicyHandler, it appears that one PolicyHandler is created for each such policy set. I wonder if it wouldn't be better to call a given PolicyHandler only once per invocation and give it the full list of policy sets it handles. This may be more efficient depending on the policy (the handler may be able to optimize/combine policies, and it may be able to find conflicts that are beyond the powers of the policy framework). Just to clarify, I did start with PolicyHanlder types classified against the PolicySet name, but later discovered that this is not scalable. Today, the PolicyHandler types are classified against the PolicyModel that they can understand (i.e. WS-Policy or some customer model) and the Intent that they can deal with (i.e authentication or transaction). I feel we might also have to add one more classifier that denotes the QoS infrastructure that the PolicyHandler is capable of working with. While the policy model and intent can be extracted for a PolicySet to find the appropriate PolicyHandler, I am not sure where we can encapsulate this 'specific infrastructure' information. So, if it does happen that we have mutliple PolicySets on a wire that point to the same PolicyHandler type, yes it makes sense to do what you suggest. Infact, this turns out to be a necessity for example when we want to configure the Axis2 Config Parameters for binding.ws to say enable authentication AND integrity where each of these could have their own PolicySets. 2. Some intents can be provided without requiring a policy set (these are the intents in the implementation's mayProvides list). Although the PolicyHandler gets registered for an intent, it appears it is only driven if the intent is satisfied by a policy set. It would be nice if it could be driven if the intent appears in the mayProvides list too. +1. At the present moment this is left to how implementation and binding extensions would choose to deal with. I'd prefer that the binding / implementation providers parse the list of required intents and if there are the ones that they 'mayProvide' then suitable PolicySets should be added to the list of PolicySets. Ofcourse the corresponding PolicyHandlers should also be defined and registered. This I feel provide uniformity and extensibility to how policy handling plugs into extensions. 3. I'm also wondering whether it should be possible to register a PolicyHandler that always gets control regardless of what intents or policy sets are specified. This might be to implement some default behavior. I'm thinking of transactions here. The transaction spec says that the runtime can provide one of the intents by default, but the choice of default is implementation-specific. There's no way to declare the default intent to the policy framework today, so there's no choice but to give control to the transaction handler and let it figure it out. This sounds like something that is left for bindings / implementations to deal with, in the way they might choose to. As I had mentioned in the previous point a cleaner way would be for binding /implementation providers to verify if a default intent needs to be in force and add the corresponding PolicySet to the list of policysets. For example, if an implementation provider parses the requiredIntents and discovers nothing in there related to transaction intent type, then it could add the default transaction PolicySet to the list of policysets. Makes sense or am I missing your point? 4. The PolicyHandler is provided the target Operation and Message. I wonder if that's enough context. Can the handler works its way up the model (component, etc) if it needs to? I suppose what is 'provided' to the handler depends on the implementation or binding extension and from where it decides to call the handlers. If the handlers are called from the interceptors they can provide any state that is available to them. Or if there is context information that is not going to change across service calls then such information could be initialized into PolicyHandlers as part of the 'setup' call. 5. It might be nice for the PolicyHandlingInterceptor constructor to make an initialization call to the handler so it can do some setup. For the JavaImplementation extension this is done in the JavaPolicyHandlingRuntimeWireProcessor that creates these PolicyHandlers and injects them into the interceptor. The 'setup' call is there as part of the
[jira] Updated: (TUSCANY-1688) XSD2JavaGenerator throws IOException:Access is denied with complexType named Con
[ https://issues.apache.org/jira/browse/TUSCANY-1688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson updated TUSCANY-1688: I did a check for EMF bugs raised for this issue, but couldn't find one. Do you know if this issue has been addressed in EMF? XSD2JavaGenerator throws IOException:Access is denied with complexType named Con -- Key: TUSCANY-1688 URL: https://issues.apache.org/jira/browse/TUSCANY-1688 Project: Tuscany Issue Type: Bug Components: Java SDO Tools Affects Versions: Java-SDO-Next Environment: Windows XP SP2 w/Sun JDK 1.4.2_11 Reporter: Ron Gavlin Fix For: Java-SDO-Next I have an XML Schema that contains a complexType named Con. The following error output is displayed to stdout: Generating Con Generating Java interface test.Con Generating /TargetProject/test/Con.java Examining old /TargetProject/test/Con.java org.eclipse.emf.common.util.WrappedException: java.io.IOException: Access is denied at org.eclipse.emf.codegen.ecore.generator.AbstractGeneratorAdapter.generateJava (AbstractGeneratorAdapter.java:1046) at org.eclipse.emf.codegen.ecore.genmodel.generator.GenClassGeneratorAdapter.generateInterface (GenClassGeneratorAdapter.java:123) at org.eclipse.emf.codegen.ecore.genmodel.generator.GenClassGeneratorAdapter.generateModel (GenClassGeneratorAdapter.java:106) at org.eclipse.emf.codegen.ecore.genmodel.generator.GenBaseGeneratorAdapter.doGenerate (GenBaseGeneratorAdapter.java:214) at org.eclipse.emf.codegen.ecore.generator.AbstractGeneratorAdapter.generate (AbstractGeneratorAdapter.java:275) at org.eclipse.emf.codegen.ecore.generator.Generator.generate (Generator.java:600) at org.eclipse.emf.codegen.ecore.generator.Generator.generate (Generator.java:512) at org.apache.tuscany.sdo.generate.JavaGenerator.generateFromGenModel (JavaGenerator.java:515) ... It seems as if the type name 'Con' conflicts with the operating system's console device named 'Con'. The code first checks to see if the file exists to decide if a merge is required. The code seems to incorrectly find the file/device named 'Con' and then tries to access it in error. I suspect this is an Eclipse EMF problem. -- 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: Graduation next steps
If someone is a very active contributor, he/she is most likely watching the commit list as well as the dev list. If someone is just subscribed to the dev list to watch the key discussions and occasionally gets involved, he/she would not want to see all the JIRA updates. This assumes that new discussions do not get triggered in JIRAs. They come to life on the mailing list and turn into a JIRA if they need to. On 2/9/08, Simon Nash [EMAIL PROTECTED] wrote: ant elder wrote: On Feb 6, 2008 5:28 PM, Simon Nash [EMAIL PROTECTED] wrote: snip One other consideration - sometimes it's appropriate to reply to a JIRA rather than updating the issue: if there are two lists, on has to decide - should the replies go to both or just dev? In such a case I think the reply should just go to the dev list. All discussions should be happening there, not on the commits list. That can be done by having the JIRA emails configured with a replyto set to the dev list, thats the same as the SVN update emails which are sent to the commit list but replies to those emails go to the dev list. If it works like that would people feel more comfortable going ahead with this change moving the JIRA emails to go to the commit list or is the dev list still the preferred place? ...ant I think the active committers could handle these on either list. It would be useful to have input from those who are not active committers and therefore (presumably) not following the commits list very closely. I'd be happy to go with whatever these people prefer. Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1688) XSD2JavaGenerator throws IOException:Access is denied with complexType named Con
[ https://issues.apache.org/jira/browse/TUSCANY-1688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12567625#action_12567625 ] Ron Gavlin commented on TUSCANY-1688: - Added as Eclipse EMF Bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=218493 XSD2JavaGenerator throws IOException:Access is denied with complexType named Con -- Key: TUSCANY-1688 URL: https://issues.apache.org/jira/browse/TUSCANY-1688 Project: Tuscany Issue Type: Bug Components: Java SDO Tools Affects Versions: Java-SDO-Next Environment: Windows XP SP2 w/Sun JDK 1.4.2_11 Reporter: Ron Gavlin Fix For: Java-SDO-Next I have an XML Schema that contains a complexType named Con. The following error output is displayed to stdout: Generating Con Generating Java interface test.Con Generating /TargetProject/test/Con.java Examining old /TargetProject/test/Con.java org.eclipse.emf.common.util.WrappedException: java.io.IOException: Access is denied at org.eclipse.emf.codegen.ecore.generator.AbstractGeneratorAdapter.generateJava (AbstractGeneratorAdapter.java:1046) at org.eclipse.emf.codegen.ecore.genmodel.generator.GenClassGeneratorAdapter.generateInterface (GenClassGeneratorAdapter.java:123) at org.eclipse.emf.codegen.ecore.genmodel.generator.GenClassGeneratorAdapter.generateModel (GenClassGeneratorAdapter.java:106) at org.eclipse.emf.codegen.ecore.genmodel.generator.GenBaseGeneratorAdapter.doGenerate (GenBaseGeneratorAdapter.java:214) at org.eclipse.emf.codegen.ecore.generator.AbstractGeneratorAdapter.generate (AbstractGeneratorAdapter.java:275) at org.eclipse.emf.codegen.ecore.generator.Generator.generate (Generator.java:600) at org.eclipse.emf.codegen.ecore.generator.Generator.generate (Generator.java:512) at org.apache.tuscany.sdo.generate.JavaGenerator.generateFromGenModel (JavaGenerator.java:515) ... It seems as if the type name 'Con' conflicts with the operating system's console device named 'Con'. The code first checks to see if the file exists to decide if a merge is required. The code seems to incorrectly find the file/device named 'Con' and then tries to access it in error. I suspect this is an Eclipse EMF problem. -- 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: NoSuchMethodError: javax/wsdl/Operation
Yes. Its the same with me as well. I have installed WAS 6.1 ND. Is there a particular fixpack that is to take care of this ? Thanks - Venkat On Feb 11, 2008 2:22 PM, ant elder [EMAIL PROTECTED] wrote: Trying to run Tuscany WebApp samples in WebSphere i get a NoSuchMethodError: javax/wsdl/Operation.getExtensibilityElements()Ljava/util/List. Anyone know how to fix that? This is with the class loader set to Classes loaded with application class loader first. ...ant
[jira] Commented: (TUSCANY-1999) ConversationAttributes and expiry doesn't work with Stateless Conversational components
[ https://issues.apache.org/jira/browse/TUSCANY-1999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12567602#action_12567602 ] Thomas Greenwood commented on TUSCANY-1999: --- Thanks Simon. It will probably be a few weeks before we get our stuff working with the latest Tuscany. As long as the interfaces between the conversation manager and the scope container are pretty similar the fix should be OK. 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]
[jira] Updated: (TUSCANY-1689) XSD2JavaGenerator generates non-compilable FactoryImpl class with complexType named Descriptor
[
https://issues.apache.org/jira/browse/TUSCANY-1689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kelvin Goodson updated TUSCANY-1689:
I did a check for EMF bugs raised for this issue, but couldn't find one. Do
you know if this issue has been addressed in EMF?
XSD2JavaGenerator generates non-compilable FactoryImpl class with complexType
named Descriptor
Key: TUSCANY-1689
URL: https://issues.apache.org/jira/browse/TUSCANY-1689
Project: Tuscany
Issue Type: Bug
Components: Java SDO Tools
Environment: Windows XP SP2 w/Sun JDK 1.4.2_11
Reporter: Ron Gavlin
Fix For: Java-SDO-Next
I have a schema with a complexType named Descriptor.
The generated FactoryImpl.java class includes the following code which does
not compile because the return type
org.eclipse.emf.ecore.EPackage.Descriptor is not compatible with
Factory.createDescriptor() with return type myNamespace.Descriptor:
public Descriptor createDescriptor()
{
DescriptorImpl descriptor = new DescriptorImpl();
return descriptor;
}
I suspect this is an EMF bug but I am reporting it here.
--
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] Commented: (TUSCANY-1831) Make SDOPackageRegistryDelegator pluggable
[ https://issues.apache.org/jira/browse/TUSCANY-1831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12567578#action_12567578 ] Kelvin Goodson commented on TUSCANY-1831: - I guess we could parallel the way that the default HelperProvider implementation is made pluggable in the SDO API project's HelperProvider class, where the default impl is looked up by PROPERTY_NAME. Make SDOPackageRegistryDelegator pluggable -- Key: TUSCANY-1831 URL: https://issues.apache.org/jira/browse/TUSCANY-1831 Project: Tuscany Issue Type: Improvement Components: Java SDO Implementation Affects Versions: Java-SDO-Next Reporter: Ron Gavlin Fix For: Java-SDO-Next The current SDOPackageRegistryDelegator implementation assumes that a standard, hierarchical classloader structure is present in the hosting environment. BEA WebLogic, for example, uses an unusual change aware classloading scheme which does not meet the expectations of the SDOPackageRegistryDelegator. Prior to Tuscany SDO 1.0, I was able to work-around this former EMF problem by setting the EMF JVM property org.eclipse.emf.ecore.EPackage.Registry.INSTANCE. In Tuscany SDO 1.0, this setting is no longer relevant. I would like to be able to plugin my own SDOPackageRegistryDelegator implementation that provides a non-classloader-aware registry, knowing full well the limitations of of this implementation. -- 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: NoSuchMethodError: javax/wsdl/Operation
And another follow up question - anyone know how to get WebSphere to start up listening for a remote debugger to attach to it? ...ant On Feb 11, 2008 8:57 AM, Venkata Krishnan [EMAIL PROTECTED] wrote: Yes. Its the same with me as well. I have installed WAS 6.1 ND. Is there a particular fixpack that is to take care of this ? Thanks - Venkat On Feb 11, 2008 2:22 PM, ant elder [EMAIL PROTECTED] wrote: Trying to run Tuscany WebApp samples in WebSphere i get a NoSuchMethodError: javax/wsdl/Operation.getExtensibilityElements()Ljava/util/List. Anyone know how to fix that? This is with the class loader set to Classes loaded with application class loader first. ...ant
[jira] Issue Comment Edited: (TUSCANY-2042) Dynamically generated WSDL not generating output message for void types
[
https://issues.apache.org/jira/browse/TUSCANY-2042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12567709#action_12567709
]
scottkurz edited comment on TUSCANY-2042 at 2/11/08 9:16 AM:
--
I recreated this at the same time as stepping through the debugger.
I saw a problem here:
Types types = definition.getTypes();
if (types != null) {
for (Object ext : types.getExtensibilityElements()) {
if (ext instanceof Schema) {
Element element = ((Schema)ext).getElement();
if
(element.getAttribute(targetNamespace).equals(namespaceURI)) {
I think the J2W is generating the WSDL definition with a TNS of http://blah;
while the schema TNS is being
generated as http://blah/xsd;.
This equals() was returning false, causing the 'document' ref to remain null,
causing a return soon after:
if (document == null) {
return;
I think I'm running on an older Axis2 level.. I wonder if that could have
anything to do with this?
was (Author: scottkurz):
I recreated this at the same time as stepping through the debugger.
I saw a problem here:
(not sure if it's the same as you
Dynamically generated WSDL not generating output message for void types
-
Key: TUSCANY-2042
URL: https://issues.apache.org/jira/browse/TUSCANY-2042
Project: Tuscany
Issue Type: Bug
Reporter: Lou Amodeo
Attachments: helloworld-ws-asynch.jar
This problem is similar to Tuscany-1658 but it appears the fix is not working
properly in all cases. I am finding that the
namespace and element namespace values assigned durig the dynamic wsdl
definition generation are causing the following code to not function because
theif (element.getAttribute(targetNamespace).equals(namespaceURI)) {
is returning false. This is because the target namespace is being generated
as : targetNamespace=http://helloworld
while the element namespace is : http://helloworld/xsd
The method signature is : public void getGreetings(String name)
class: Java2WSDLHelper.java
private static void processNoArgAndVoidReturnMethods(Definition definition,
Class javaInterface) {
String namespaceURI = definition.getTargetNamespace();
String prefix = definition.getPrefix(namespaceURI);
String xsPrefix =
definition.getPrefix(http://www.w3.org/2001/XMLSchema;);
PortType portType =
(PortType)definition.getAllPortTypes().values().iterator().next();
Element schema = null;
Document document = null;
Types types = definition.getTypes();
if (types != null) {
for (Object ext : types.getExtensibilityElements()) {
if (ext instanceof Schema) {
Element element = ((Schema)ext).getElement();
if
(element.getAttribute(targetNamespace).equals(namespaceURI)) {
schema = element;
document = schema.getOwnerDocument();
break;
}
}
}
}
if (document == null) {
return;
}
Definition generated:
Definition: name=null targetNamespace=http://helloworld
Types:
SchemaExtensibilityElement ({http://www.w3.org/2001/XMLSchema}schema):
required=null
element=[xs:schema: null]
Message: name={http://helloworld}getGreetingsMessage
Part: name=part1
elementName={http://helloworld/xsd}getGreetings
PortType: name={http://helloworld}HelloWorldServicePortType
Operation: name=getGreetings
style=ONE_WAY,0
Input: name=null
Message: name={http://helloworld}getGreetingsMessage
Part: name=part1
elementName={http://helloworld/xsd}getGreetings
Binding: name={http://helloworld}HelloWorldServiceSOAP12Binding
PortType: name={http://helloworld}HelloWorldServicePortType
Operation: name=getGreetings
style=ONE_WAY,0
Input: name=null
Message: name={http://helloworld}getGreetingsMessage
Part: name=part1
elementName={http://helloworld/xsd}getGreetings
BindingOperation: name=getGreetings
BindingInput: name=null
SOAPBody ({http://schemas.xmlsoap.org/wsdl/soap12/}body):
required=null
use=literal
namespaceURI=http://helloworld
SOAPOperation ({http://schemas.xmlsoap.org/wsdl/soap12/}operation):
required=null
soapActionURI=urn:getGreetings
style=document
SOAPBinding ({http://schemas.xmlsoap.org/wsdl/soap12/}binding):
required=null
transportURI=http://schemas.xmlsoap.org/soap/http
style=document
Binding: name={http://helloworld}HelloWorldServiceSOAP11Binding
PortType: name={http://helloworld}HelloWorldServicePortType
Operation: name=getGreetings
style=ONE_WAY,0
Input: name=null
Message:
SCA and Databases
Dear All, I have a question around SCA and Java embedded in a database. How feasible is it to embedded SCA within say the Java VM running within an Oracle database, either to provide a service or as a client to call a service. I have a scenario in mind that goes essentially like this: 1. Some database logic (e.g. PL/SQL) calls a piece of Java code 2. Java code needs to call out to an external service – for example to access an external Work Order system to obtain a new work order id 3. Java code calls an SCA client, using (say) the Web Services binding to access the remote service direct from within the database 4. Obtains a new id back and continues? Obviously the Database JVM must be able to support the appropriate version of Java etc. but what else might be required. Potentially hosting services is more of an issue – however, in some cases it might be useful to define a Java POJO that will invoke PL/SQL within the database for performance issues (obviously we could create a POJO external to the database that could call the PL/SQL / stored procedures externally). However, I suspect that this is a rather more problematic area. For example, depending upon the binding selected what functionality is required in the database - how would a web service, rmi or jms binding be supported (if indeed at all). In terms of real world scenarios I know of numerous situations in which the SCA client in the database scenario would be very useful. I have less “real world” scenarios for the service in the database example. But should the ability to at least run an SCA Client from within the database be a supported SCA scenario? I would be very interested to know what the SCA Dev community think about this. Regards, John - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Distribution zips and what they contain, was: SCA runtimes
Comments inline. Simon Nash wrote: Well, I think the smart installer approach will be a nightmare. We had a similar approach in M2 and people didn't like it. The M2 approach was very different from what I was proposing. M2 downloaded everything on demand at runtime. A smart installer would set things up ahead of time with the necessary features for the desired runtime configuration. This is much more manageable if there are any problems with the downloads. OK, you scared me :) If you're talking about analyzing the features required by a composite at deployment time, calculating the set of JARs providing these features, and making them available for installation, then you get my +1. The work I've started with the Maven Ant generator plugin is a step in that direction. If you hook it with a composite model analyzer and remove the Ant specifics you get what I just described, allowing you to tailor a minimal runtime for a particular SCA application. You're right that the Eclipse feature install approach is a little like that. IMHO it has been a nightmare and probably one of the reasons why their download page [1] now shows targeted distros :) - for Java developers - for Java EE developers - for Plugin developers - for C++ developers - for Web developers (on a separate page). - and the classic IDE mix Very similar to the approach I was proposing... I'm just seeing Spring and Eclipse, two extensible and successful projects adopt similar approaches, and thought they'd be good examples to follow :) I think these are good examples to follow. Tuscany is rather similar in that it contains a base framework and many optional extensions, and there is probably no user who wants to use all the optional features. +1 But that's OK, if people don't like that split I can also live with a single big runtime distro. Over time, we will add more and more optional features and this will become more and more of a problem. IMO, it's bad enough now that we need to do something. I agree with you, but there is no consensus on this. I see several options: a) a vote to pick a common direction now b) have people develop their different visions to get user feedback c) continue with the current distro scheme Like I said I could live with (c). However, I would prefer (a) or (b). I'd like to suggest a first baby step towards partitioning the contents of the distro. In this first step, there's still a single binary distro with all the dependencies. The difference is that the modules and lib directories are broken down into subdirectories along the lines that Sebastien and others have suggested. Based on earlier discussions, the subdirectories could be: core - The base that everybody needs core assembly model and runtime Java APIs, Java components, SCA binding, Web Service binding web - For Web developers Web 2.0 bindings, Scripting components, Widget components JEE - For JEE app integration EJB, RMI and JMS bindings, Spring components process - For process development BPEL and XQuery components Each of these could be built and tested separately. Dependencies between them would only use documented SPIs. There would no longer be a single catch-all tuscany-manifest jar or a single tuscany-all jar. If this first step is successful, we could think about what further steps we could take to improve modularity. I don't see what that baby step buys us. If we think that partitioning is the right approach, why not just simply do it cleanly and partition the distro? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
