Re: Can't generate a Java interface from a WSDL portType

[Simon Nash]

Scott Kurz wrote:

Simon,

The question is do we look at the definitions of the WSDL document
defining the imported portType
or the definitions of the document defining a WSDL service in terms of the
imported portType  (since the TNS
of each are different).

I haven't read all of JAX-WS either but agree that the CXF behavior makes
more sense.

If you consider the question which definitions? it seems you'd naturally
pick the one in which
the portType is actually DEFINED as opposed to merely IMPORTED


From what I can see the WSDL spec doesn't say anything particular about the

import behavior either.

On the one hand this isn't too critical since, with either choice, we
generate a just-as-legal
@WebService(targetNamespace)
into the Java to capture the original TNS.


Doesn't this raise the same question?  The @WebService annotation
for the generated Java interface should have the targetNamespace
of the portType.  It seems an extremely reasonable assumption
that this is the same targetNamespace of the portType (whatever
that means) that will be used to derive the package name.

I tried this with the Sun RI and was surprised that it took the
targetNamespace for the @WebService annotation from the portType's
wsdl:definitions, even though it took the targetNamespace for
the package name from the service's wsdl:definitions.

This inconsistency seems wrong to me.  My conclusion is that
CXF has got this right.


On the other hand, JAX-WS could have been clearer on this...


I agree.  And this seems like a warning that in cases where the
spec is ambiguous, we should not assume that we can use the
Sun RI's behaviour to determine which interpretation is correct.

  Simon






On Mon, Jun 9, 2008 at 4:45 AM, Simon Nash [EMAIL PROTECTED] wrote:


Jean-Sebastien Delfino wrote:


Scott Kurz wrote:


Sebastien, I'm surprised the package names would be different.What is
the namespace you're using that isn't mapping to the same package in each
tool?
Just curious...



My app is an order processing app with the following:

WSDL service namespace:
http://sample/Order/Binding

WSDL Order portType namespace:
http://sample/Order

The CXF tool generates interface sample.order.Order
The JAXWS RI tool generates interface sample.order.binding.Order

I gave the same WSDL file (containing the WSDL service) to both tools.

One could argue that both are correct vs the JAX-WS spec as they generate
a correct package name from the namespace of 'the' WSDL definition, but the
funny thing is that they do not pick the same WSDL definition... JAXWS-RI
picks the input definition given to the tool and CXF the definition that
actually contains the portType... and the JAXWS spec doesn't seem to state
which one should be picked (at least I couldn't find it).

IMHO the CXF behavior is better, but I've not read all 150 pages of the
JAX-WS spec so I may be missing something :)



From section 2.2 of the JAX-WS spec:

 A wsdl:portType element is mapped to a Java interface in the package
 mapped from the wsdl:definitions element (see section 2.1 for a
 description of wsdl:definitions mapping).

Section 2.1 says:

 A wsdl:definitions element and its associated targetNamespace
 attribute is mapped to a Java package. JAXB[10] (see appendix D)
 defines a standard mapping from a namespace URI to a Java package
 name. By default, this algorithm is used to map the value of a
 wsdl:definitions element's targetNamespace attribute to a Java
 package name.

 } Conformance (Definitions mapping): In the absence of customizations,
 the Java package name is mapped from the value of a wsdl:definitions
 element's targetNamespace attribute using the algorithm defined by
 JAXB[10].

So IMO the Java package name that's used to map the portType should
be derived from the targetNamespace of the wsdl:definitions element.
What was this targetNamespace?

 Simon

Re: Can't generate a Java interface from a WSDL portType

[Simon Nash]

Jean-Sebastien Delfino wrote:

Scott Kurz wrote:

Sebastien, I'm surprised the package names would be different.What is
the namespace you're using that isn't mapping to the same package in each
tool?
Just curious...



My app is an order processing app with the following:

WSDL service namespace:
http://sample/Order/Binding

WSDL Order portType namespace:
http://sample/Order

The CXF tool generates interface sample.order.Order
The JAXWS RI tool generates interface sample.order.binding.Order

I gave the same WSDL file (containing the WSDL service) to both tools.

One could argue that both are correct vs the JAX-WS spec as they 
generate a correct package name from the namespace of 'the' WSDL 
definition, but the funny thing is that they do not pick the same WSDL 
definition... JAXWS-RI picks the input definition given to the tool and 
CXF the definition that actually contains the portType... and the JAXWS 
spec doesn't seem to state which one should be picked (at least I 
couldn't find it).


IMHO the CXF behavior is better, but I've not read all 150 pages of the 
JAX-WS spec so I may be missing something :)


From section 2.2 of the JAX-WS spec:

 A wsdl:portType element is mapped to a Java interface in the package
 mapped from the wsdl:definitions element (see section 2.1 for a
 description of wsdl:definitions mapping).

Section 2.1 says:

 A wsdl:definitions element and its associated targetNamespace
 attribute is mapped to a Java package. JAXB[10] (see appendix D)
 defines a standard mapping from a namespace URI to a Java package
 name. By default, this algorithm is used to map the value of a
 wsdl:definitions element’s targetNamespace attribute to a Java
 package name.

 } Conformance (Definitions mapping): In the absence of customizations,
 the Java package name is mapped from the value of a wsdl:definitions
 element’s targetNamespace attribute using the algorithm defined by
 JAXB[10].

So IMO the Java package name that's used to map the portType should
be derived from the targetNamespace of the wsdl:definitions element.
What was this targetNamespace?

  Simon

New Java2WSDL runtime generator is now active in the build

[Simon Nash]

I've committted r660340 which adds supports for static SDOs to the
new Java2WSDL runtime generator and fixes a few problems.  For
static SDOs generated from XSDs, the contribution is searched
for the original XSD definitions, and these are included in the
generated WSDL.

These changes are enough to get a full build to run, so I've turned on
the new generator code by default.  More testing is still needed, and
it's possible that this new code could cause problems.  If you see
anything unexpected in a Java2WSDL scenario (including the distributed
SCA binding, which uses Java2WSDL under the covers), please open a
JIRA and I'll look at it right away.

One interesting side-effect of these changes is that the tutorial
now builds cleanly for me.  Previously it was failing.

  Simon

Re: handling InputStream as a service parameter

[Simon Nash]

Eugeny N Dzhurinsky wrote:

Hello there!

I noticed there's no way to define a service which accepts an InputStream and
returns an InputStream as a result (in fact it is possible to start such
service, but when a client calls the service - the XML error Content is not
allowed in prolog raises somewhere inside transformer:

org.apache.tuscany.sca.databinding.TransformationException: 
org.apache.tuscany.sca.databinding.TransformationException: 
javax.xml.transform.TransformerException: org.xml.sax.SAXParseException: 
Content is not allowed in prolog.
at 
org.apache.tuscany.sca.databinding.xml.InputStream2Node.transform(InputStream2Node.java:48)
at 
org.apache.tuscany.sca.databinding.xml.InputStream2Node.transform(InputStream2Node.java:37)
at 
org.apache.tuscany.sca.databinding.DefaultTransformerExtensionPoint$LazyPullTransformer.transform(DefaultTransformerExtensionPoint.java:199)
at 
org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImpl.java:73)
at 
org.apache.tuscany.sca.core.databinding.transformers.Input2InputTransformer.transform(Input2InputTransformer.java:148)
at 
org.apache.tuscany.sca.core.databinding.transformers.Input2InputTransformer.transform(Input2InputTransformer.java:43)
at 
org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImpl.java:73)
at 
org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterceptor.transform(DataTransformationInterceptor.java:186)
at 
org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterceptor.invoke(DataTransformationInterceptor.java:76)
at 
org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:286)
at 
org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:154)
at $Proxy8.handleImage(Unknown Source)
)

As a workaround I am passing and returning the arrays of bytes, however I
don't really like such approach. And I hope there's some way to provide custom
data binding for InputStream objects (stating them just a byte streams - not a
complex objects).

I am using WS-bindings, if that matters, and tuscany 1.2.

Could somebody please advice? May be using web services isn't a good idea to
pass and return a large BLOB for the service (image transformation in my
case)?


If this is going over Web services, the contents of the stream
would need to be transmitted on the wire as an array of bytes.
An InputStream can't be passed over Web services in its Java object
form.  Do you want to pass an InputStream in this case so that you
can avoid copying the same data multiple times during marshalling?
If so, it should be possible to write a custom data binding that
only does a single copy.

For a local (intra-JVM) invocation using the default binding, it
would be possible to write a custom data binding to pass an
InputStream as a Java object.  Is this relevant to your application
requirement?

  Simon

Re: wsdl reference question

[Simon Nash]

Abraham Washington wrote:

sorry, should have included the code.  this is just the calculator-ws-webapp 
composite (which is below).  i added this code:
service name=CalculatorService 
promote=CalculatorServiceComponentbinding.ws//service
which exposes the CalculatorService.  but, now the wsdl has operations like:
setAddService
setDivideService
i don't want to expose the methods to the outside world.   is there a way 
around that ?


Just put @Remotable on the CalculatorService interface.  Without
this, the class is introspected to derive the WSDL service definition.
With this, only the interface will be introspected.

  Simon


thx abe?xml version=1.0 encoding=UTF-8?
!--
* Licensed to the Apache Software Foundation (ASF) under one
* or more contributor license agreements. See the NOTICE file
* distributed with this work for additional information
* regarding copyright ownership. The ASF licenses this file
* to you under the Apache License, Version 2.0 (the
* License); you may not use this file except in compliance
* with the License. You may obtain a copy of the License at
* 
* http://www.apache.org/licenses/LICENSE-2.0
* 
* Unless required by applicable law or agreed to in writing,

* software distributed under the License is distributed on an
* AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
* KIND, either express or implied. See the License for the
* specific language governing permissions and limitations
* under the License. 
--

composite xmlns=http://www.osoa.org/xmlns/sca/1.0;
targetNamespace=http://sample;
xmlns:sample=http://sample;
name=Calculatorservice name=CalculatorService 
promote=CalculatorServiceComponentbinding.ws//servicecomponent name=CalculatorServiceComponent
implementation.java class=calculator.CalculatorServiceImpl/
reference name=addService 
interface.java interface=calculator.AddService / 
binding.ws uri=http://localhost:8080/sample-calculator-ws-webapp/AddServiceComponent/ 
/reference 
reference name=subtractService target=SubtractServiceComponent/reference

reference name=multiplyService target=MultiplyServiceComponent/reference
reference name=divideService target=DivideServiceComponent/reference
/component
component name=AddServiceComponent
implementation.java class=calculator.AddServiceImpl/
service name=AddService
interface.java interface=calculator.AddService / 
binding.ws/

/service
/component
component name=SubtractServiceComponent
implementation.java class=calculator.SubtractServiceImpl/
/component
component name=MultiplyServiceComponent
implementation.java class=calculator.MultiplyServiceImpl/
/component
component name=DivideServiceComponent
implementation.java class=calculator.DivideServiceImpl/
/component
/composite



- Original Message 
From: Mike Edwards [EMAIL PROTECTED]
To: tuscany-user@ws.apache.org
Sent: Wednesday, April 30, 2008 4:41:26 AM
Subject: Re: wsdl reference question

Abraham Washington wrote:
hi all, i have a service that has a reference to another service.� so, 
in my impl class there's a setter method for the reference.�� when the

app is deployed, the wsdl generates the setter method operation, thus
making it available to be invoked (not a good thing).�
is there a way around this ?
thx abe


  

Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

Hi Abe,

Can you explain what your app is doing in some more detail - maybe post 
some code and the composite file?


If you have declared a reference in your code, with a setter method, 
then I would expect the setter method to get called at runtime with the 
reference proxy for the target service that you configure in your 
composite file.


For the setter method to get included in the WSDL generated for the 
service offered by the component, then:


a) presumably you are not marking the service offered by the 
implementation code, so that the defaulting process is happening

- you do this by using the @Service annotation

b) also, I suspect that your class does not say something like

public fooClass implements barInterface {
...
}

- since the default service generation will look at the barInterface to 
generate the WSDL for the service.  If there is no implements clause 
then the SCA code has little to go on as to which methods should be 
included.  In this case, as the SCA Java Client  Implementation 
specification says:


If none of the implemented interfaces is remotable, then by default the 
implementation offers a single service whose type is the implementation 
class.


I recommend that you consider using one of the above techniques to 
control which class methods are used for the operations of the Service 
interface.



Yours, Mike.



  

Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it 

Re: Typical Use Cases for ServiceReference.getCallback()?

[Simon Nash]

Yee-Kang Chang wrote:

Hello,

I could not find any description on how this method -- getCallback() of a 
ServiceReference -- should be used in the Java Annotations  APIs 
specification.  May I know what would be the typical use cases for it?  I 
understand RequestContext.getCallback() (and 
ServiceReference.setCallback(Obj)) but I'm having a hard time getting 
around ServiceReference.getCallback().  Any help is much appreciated.


Thank you!


This method is the getter that matches the setCallback(Obj) method
of ServiceReference.  It retrieves the value that was previously set
using setCallback(Obj).  This follows the Java convention that
setter methods usually have a corresponding getter.

  Simon

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

Re: SCA 2.0, was Re: Next SCA release

[Simon Nash]

Comments inline.

  Simon

Simon Laws wrote:

On Thu, Apr 10, 2008 at 12:43 PM, Mark Combellack [EMAIL PROTECTED]
wrote:


-Original Message-
From: ant elder [mailto:[EMAIL PROTECTED]
Sent: 10 April 2008 12:26
To: [EMAIL PROTECTED]
Subject: Re: SCA 2.0, was Re: Next SCA release

On Thu, Apr 10, 2008 at 12:01 PM, Simon Laws [EMAIL PROTECTED]
wrote:


On Thu, Apr 10, 2008 at 8:12 AM, ant elder [EMAIL PROTECTED]

wrote:

On Wed, Apr 9, 2008 at 10:23 PM, Jean-Sebastien Delfino 
[EMAIL PROTECTED] wrote:

snip



1.3 sounds good to me. I'm assuming that we'll cut that branch out

of

trunk?

I'm asking because I'm interested in working on some improvements

of

1.2

in the next few weeks. This shouldn't delay any 2.0 work however,

which

can

go in parallel.



That sounds scary.

Are you saying you don't think its the right time for 2.0? I started

this

discussion to see if there was consensus to move to 2.0, if there's

not

consensus then we should not do it. The last thing we need is dev

going

on

in multiple branches as happened in the old days.

  ...ant


Maybe this means we should consider the trunk to be 1.X and branch for

2.0

at the point at which someone wants to start investigating 2.0. I've

been

thinking of this 2.0 exercise as investigative in the first instance

hence

[1]. By that I mean that I would fully expect us to do other 1.X

releases

before any 2.0 features appear in released form.


This is my expectation as well.


B.t.w - have copied in the user list as we neglected to do this and

this

is
as much a user discussion as a developer discussion.

Simon


Keeping maintenance branches going and porting fixes from trunk back to
them
seems fine but as has been demonstrated several times in Tuscany's

history

we are not able to maintain a consensus based approach to development

when

new development is going on in multiple branches. If we're not ready to
make
backward compatibility breaking changes to the trunk code then IMHO we
should just wait.

   ...ant


It all depends on the development focus. I am presuming that:

  * Version 2.x will be the main focus
 * Most of the development effort happens on Version 2.x
 * We will make API changes which means that it will not be backwards
compatible with version 1
  * Version 1.x will go into maintenance mode.
 * May get some bug fixes and minor updates

If my presumptions are correct then, from my point of view, we should keep
the trunk as the most up to date version - i.e. Version 2.

Any maintenance for previous Version 1.x release should be done on their
own
branches.


I don't think we are ready yet to retire the 1.x codebase to the
extent that's stated here.  Like Sebastien, I plan to work on
improvements to the 1.x codebase over the next few weeks.




ant also makes an interesting point about timing. Without clear goals and
objectives for Version 2.x, perhaps we should hold off on branching.


+1.  Many of the items suggested for 2.0 have previously been the
subject of discussions that have not been easy to close.  Until
we have agreement on how to approach these things, I think it's
better for 2.0 development to happen in an investigative branch.
Doing this will allow us to try different approaches and see
which we prefer, without causing a lot of churn to the trunk.


Mark



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



Hi Mark

I agree and specifically on your last point this was the basis of my comment
about us being in the investigation stage, i.e. working out what our goals
are. We definitely don't have a clear view of those at the moment other than
the hazy things that we haven't yet clearly articulated. I don't have any
feeling that we are in the position to jump into V2.0 development with a
view to doing a release any time soon.


+1.


I would also like to hear some user input on the things that are really
important and whether they fall into the category of V2.0 breaking changes
or V1.X compatible changes.


I think this is very important.  I'd like to take the current 1.x
codebase as far as we can without making breaking changes, and
I don't think we have reached that point yet.  When we have a list
of things that
 1. we agree need doing, and how to do them
 2. are based on user requirements
 3. can't be done in 1.x
I think that would be the right time to switch the main project focus
over to the 2.0 codebase.

  Simon

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

Re: Change the ws binding uri

[Simon Nash]

Pedro David Lopez wrote:

Hi, I have this reference in the composite file and works fine

reference name=AdminAccessService
promote=AdminAccessServiceComponent/gwAdminAccess
requires=authentication
interface.java
interface=com.ptb.gwaccess.servicecomponents.AdminAccess/
binding.ws uri=http://192.168.1.254:8085/gwadmin/
 /reference

But I need to change the binding ws uri in runtime. I am trying to do this:

ListComponentReference references =
scaDomain.getComponentManager().getComponent(AdminAccessServiceComponent).getReferences();

/* Setting the service url for binding */
for (ComponentReference ref : references) {
if (ref.getName().equals(AdminAccessService)) {
for (Binding b : ref.getBindings()) {
b.setURI(url+name);

}
}
}


This won't do what you expect, because the URI that used to make
WebService invocations is part of an Invoker object that's created
at deployment time from the binding information.  Tuscany does not
currently permit you to get to Invoker objects and update them
at runtime.

The SCA philosophy is that applications deal only with references
and don't control how those references are resolved to specific
service endpoints.  Making the kind of update you are describing
from within an application would be contrary to this philosophy
because it requires the application to know about binding types
and endpoint addresses.

However, there could be use cases where some admin or management
code would want to make changes like this.  I'm not sure whether
they should be applied to deployed components that are currently
running, or just to new deployments.

Can you say more about your application and why it needs this
capability?  In particular, does the URI change need to affect
a running application without redeployment?

  Simon


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

Re: namespace mismatch calling Axis2 service

[Simon Nash]

Comments linline.

  Simon

Albert Rainer wrote:

Hi, I've followed the advice from Raymond in order to be able to call a remote 
Web service that is not under the control of tuscany.
I'm facing the problem that when I invoke the (Axis2) service, I get an 
exception that indicates a problem with the namespace.
Can anybody give me an hint what I'm doing wrong?
thanks very much in advance

Albert

SCHWERWIEGEND: Exception occurred while trying to invoke service method addiere
org.apache.axis2.AxisFault: namespace mismatch require http://move.at/xsd found
http://move.at
at org.apache.axis2.rpc.receivers.RPCMessageReceiver.invokeBusinessLogic
(RPCMessageReceiver.java:103)
at org.apache.axis2.receivers.AbstractInOutSyncMessageReceiver.receive(A
bstractInOutSyncMessageReceiver.java:39)
at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:144)
at org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostReq
uest(HTTPTransportUtils.java:279)
at org.apache.axis2.transport.http.AxisServlet.doPost(AxisServlet.java:1
16)  ...



The Implementation of the service looks like:

package at.move;
public class MathService {
public double addiere(double a,double b){
return a+b;
}
public int aufrunden(double a){
return (int)Math.ceil(a);
}
}

Deployed at http://localhost:8080/zong


The WSDL is auto-generated by AXIS2. (For some reasons I do not know AXIS adds 'xsd' to the namespace)

(WSDL files from the tuscany samples do not show that /xsd suffix)
 
...
wsdl:types

xs:schema attributeFormDefault=qualified elementFormDefault=qualified 
targetNamespace=http://move.at/xsd;
xs:element name=addiere
xs:complexType
xs:sequence
xs:element name=a nillable=true 
type=xs:double/
xs:element name=b nillable=true 
type=xs:double/
/xs:sequence
		/xs:complexType   
   ... 
   
In another web application I have (from the calculator example):


composite xmlns=http://www.osoa.org/xmlns/sca/1.0;
   targetNamespace=http://sample;
   xmlns:sample=http://sample;
   name=Calculator 
component name=CalculatorServiceComponent
		implementation.java class=calculator.CalculatorServiceImpl/   
		reference name=addService 
binding.ws uri=http://localhost:8080/zong/services/MathService; /
/reference

/component
...
 

From your description, it sounds like the Tuscany side is using WSDL
that's auto-generated by Tuscany, and the Axis2 side is using WSDL
that's auto-generated by Axis2.

In general this is not advisable, as any difference between the
auto-generation algorithms will lead to interoperability errors,
as you are seeing.  For assured interoperability, it is safest
to either use explicitly generated WSDL on both sides, or to
use auto-generation on one side (I'll call it side A) and explicit
WSDL other the other side (I'll call it side B), where the explicit
WSDL was generated by side A's tools.  That way you know that both
A and B are running from the same WSDL definitions.

In this case it looks to me like you might be using Axis2 1.2
to host the MathService.  Axis2 1.2 adds this /xsd suffix to the
schema namespace, but Axis2 1.3 does not.  Tuscany uses Axis2 1.3,
so its auto-generated WSDL won't have this /xsd suffix.  You can
either upgrade the MathService to Axis2 1.3, or follow the best
practice for interoperability using explicit WSDL as described above.

  Simon

 I have an Interface:
 
 package at.move;

 import org.osoa.sca.annotations.Remotable;

/**
 * The interface for the add service
 */
@Remotable
public interface RemoteMathService {

double addiere(double n1, double n2);
public int aufrunden(double a);

}

And a calculator implementation:

...
private RemoteMathService addService;

@Reference
public void setAddService(RemoteMathService addService) {
this.addService = addService;
}

public double add(double n1, double n2) {
 return addService.addiere(n1, n2);
}

The application is deployed at http://localhost:8080/sample-calculator-ws-webapp

Dr. Albert Rainer
EC3 - Electronic Commerce Competence Center
www.ec3.at
Donau-City Strasse 1
A-1220 Wien
Tel: +43 1 522 71 71 - 33
Fax: +43 1 522 71 71 - 71


-
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: Sending message to Tuscany

[Simon Nash]

Joshua Jackson wrote:

Dear all,

Is it possible to send message to Tuscany? I've got this Interactive
Voice Response program made by a vendor and it is able to send a
message to a socket. Now, can tuscany receive those message from a
certain port and then send back the response to the IVR ?

Thanks in advance


Hi Joshua,
Tuscany supports the use of custom protocols like this through the
ability to create a binding extension.

Is the message to the socket sent using HTTP, or does it use some
other custom protocol?  If it is HTTP, we have a number of bindings
in Tuscany that do this kind of thing and it would not be hard to
adapt one of these to do what you need.  If it is a custom protocol,
you will need to write a bit more code to handle the socket protocol
yourself in the binding, but it shouldn't be too bad.

For examples of how to write bindings in Tuscany you can look at the
bindings that Tuscany provides for Axis2 Web Services, JMS, RMI, JSON,
Atom, RSS, etc.  There is also a sample called binding-echo-extension,
but (unfortunately) I don't think the code in this is as easy to
understand as some of the other bindings that I mentioned.

I'd be interested in working with you to help you create a custom
socket binding, especially if it could be used to derive a simple
sample that Tuscany can use to show how to do something like this.

  Simon

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

Re: commercial support for Tuscany

[Simon Nash]

Evo Eftimov, iSec Consulting, www.isecc.com wrote:

Hello, our company is considering using Tuscany SCA container as part of an
end-to-end SOA solution.

 


Can a customer support representative contact  me to discuss details like
subscription packages for support etc

 


Regards

 


Evo



Hello Evo,
As far as I know there are no commercial support offerings for Tuscany.
This seems like a business opportunity for someone :-)

As an open source project, we do our best to support our users but we
cannot make any specific commitments to support levels.  Support is
provided on a best effort basis via the tuscany-user and tuscany-dev
mailing lists and the Tuscany JIRA system.  You can take a look at
examples of user questions and problem reports to see the level of
responsiveness that users typically receive.  In general I think we
do quite well at addressing and resolving most questions and problems
promptly, but in some cases for various reasons we may not be able to
provide functionality that users request.  In such cases we welcome
contributions from anyone interested in getting involved, and we are
always willing to help people who want to do this.

  Simon


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

Re: What should be in Tuscany SCA Java release 1.2?

[Simon Nash]

+1 for Luciano as RM.  Thanks, Luciano!

  Simon

Raymond Feng wrote:

+1 on Luciano as the RM for 1.2.

Thanks,
Raymond
--
From: Luciano Resende [EMAIL PROTECTED]
Sent: Tuesday, March 04, 2008 9:36 AM
To: tuscany-user@ws.apache.org
Cc: tuscany-dev [EMAIL PROTECTED]
Subject: Re: What should be in Tuscany SCA Java release 1.2?


Time flies and is already March. I'd like to restart discussion on
this thread and start building a list of things we want to do for SCA
1.2 and I'd also like to volunteer for Release Manager for SCA 1.2
release.

On Thu, Feb 14, 2008 at 8:52 AM, Simon Laws 
[EMAIL PROTECTED] wrote:

Hi

 It's probably about time we started talking about what's going to be in
 Tuscany SCA Java release 1.2. From the past timeline I would expect 
us to be

 trying for a release mid to late March which is not very far away.

 Some of the things I'd like to see are;

 More progress on our domain level composite and generally the 
processing

 that has to go there
 There have been a lot of policy changes going on and it would be 
good to get
 them in. Also linked to the item above we should look at how policy 
affects

 domain level processing.
 Don't know if it's achievable but some elements of the runtime story 
we have

 been talking about on the mail list for a while now

 Feel free to add topics on this thread. I've also opened up the
 Java-SCA-1.2category in JIRA so start associating JIRA with it, for
 example, if

 1 - you've already marked a JIRA as fixed and its sitting at 
Java-SCA-Next

 2 - you are working or are going to work on the JIRA for 1.2
 3 - you would like to see the JIRA fixed for 1.2

 Of course everyone is invited to contribute and submit patches for JIRA
 whether they be for bugs or new features. Inevitably not all wish 
list
 features will get done so you improve your chances of getting you 
favorite

 feature in by submitting a patch for it.

 Regards

 Simon





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





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

Re: Build process fails on german system

[Simon Nash]

Luciano Resende wrote:

In this particular sample scenario, what if we always set the system
property in case of a SecurityException ? This would avoid issues in
multiple/different languages.


It feels like a hack, as it could pick up the wrong exception condition.
Despite this, I think it's the best solution for this issue.  We should
never be comparing the text of the detail string.

  Simon


On Wed, Feb 20, 2008 at 9:23 AM, Mike Edwards
[EMAIL PROTECTED] wrote:

Hmm,  this looks like one of the those flaws in Java exceptions - there
 is no way of having something like a number to uniquely identify an
 exception beyond its class - using strings is a bad idea, for exactly
 this issue with language conversions.

 This has led to the message string being used to identify sub-cases for
 exception types, with nasty consequences as found here.

 I suppose the pure way of doing it would be for there to be a subclass
 of SecurityException that deals with the case of not being able to find
 a LoginConfiguration.  But I can understand that it quickly gets tedious
 to create ever more new exception classes. So people don't.


 Yours,  Mike.


 [EMAIL PROTECTED] wrote:



Hi,

 
  Could you please let me know what was the exception you had to modify ?
 
  Of course. Here's the diff, the file is in
  java\sca\samples\calculator-implementation-policies\src\test\java\calculator\
 
  Index: CalculatorTestCase.java
  ===
  --- CalculatorTestCase.java   (revision 629059)
  +++ CalculatorTestCase.java   (working copy)
  @@ -38,7 +38,7 @@
   try {
   Configuration secConf = Configuration.getConfiguration();
   } catch ( java.lang.SecurityException e ) {
  -if ( e.getMessage().equals(Unable to locate a login 
configuration) ) {
  +if ( e.getMessage().equals(Anmeldekonfiguration kann nicht gefunden 
werden.) ) {
   System.setProperty(java.security.auth.login.config, 
target/classes/CalculatorJass.config);
   } else {
   throw e;
 
  Cheers,
  Jürgen.
 
 
  -
  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]









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

Re: [Cross Subproject Discussion] options for SDO Java in Apache

[Simon Nash]

It would be good to keep this discussion on tuscany-user and not have it
intermingled across the tuscany-user and tuscany-dev lists.

Other comments inline.

  Simon

ant elder wrote:

On Feb 15, 2008 10:39 AM, Mike Edwards [EMAIL PROTECTED]
wrote:


Folks,

A few observations inline.

Ron Gavlin wrote:

I think consolidating the two SDO implementations under a single
implementation would be good for the entire Apache SDO community. My

concern

would be that no Tuscany SDO features be lost in the transition. The
new implementation should provide most of what I can currently achieve
using both EMF and Tuscany SDO. For example, EMF features like

integrated validation should be

available in the new implementation before the old implementation is

dumped. It might be a good idea to poll the Tuscany SDO community to
identify the EMF features currently being used by Tuscany SDO community. It
might also be interesting to poll the Eclipse EMF SDO 1.0 community and
ask the same question. Maybe many of the existing Tuscany SDO test cases
could be re-written for either 1). the new implementation  or 2). the CTS,
to minimize the loss of functionality during the transition.

There is a fundamental tension here which I think it is important to
recognise.

On the one hand, we want to ensure a lively and progressive Apache SDO
community that continually extends the capabilities of SDO to better
suit the needs of users.  Innovation is a bit part of this story.

On the other hand, we're trying to promote an open (and open source)
approach to the standardization of the SDO interfaces, to help ensure
consistent implementation of SDO across products both commercial and
open source.  There is a JSR and a set of activities taking place in
OASIS for this.  Part of that work is to produce an RI and a TCK, open
to all.  However, an RI must be just that - an exemplary implementation
of the specification, the whole specification and nothing but the
specification.  Similarly, the TCK must be testing compliance of
implementations with the specification, the whole specification and
nothing beyond the specification.  This demands limitations on innovation.

So, there is some careful work required in building both forward-looking
innovative capabilities and at the same time creating somewhat rigid RIs
and TCKs, which are inevitably tied to specific versions of a
specification.  I think that the proposal to have a second SDO project
in Apache is regarded as one way to approach these conflicting
requirements.  It may not be the only way, but at least it would provide
clear dividing lines that both contributors and users can understand
easily.

It will take some careful thought to combine these aspects within one
project in a way that works for all contributors and for all users.


+1.  This will be one of the biggest challenges in bringing these two
SDO efforts together.


One of the reasons that Tuscany is NOT an RI and does NOT contain a TCK
for SCA is because it fosters freedom in the implementation of new
capabilities that go well beyond the current SCA specifications.  Some
of these will feed into future standard specifications, I'm sure.


+1.  I think it's important to retain this freedom for Tuscany to
innovate and not be constrained to exactly match any particular level
of the specs that it implements.


From my perspective, the priorities for Apache SDO moving forward should

be:

1. Align Apache SDO with the JAXB specification.
The static SDO implementation should be JAXB-compliant.

2. Align Apache SDO with the JPA specification. It should be simple to

use a OpenJPA to persist SDO graphs.

3. Provide data binding support for popular Java open source WS stacks,

especially Axis2 and CXF.
Yes, all good innovative stuff.

I could toss in a few more, such as having an SDO implementation for
JavaScript to address AJAX applications.

But how to square this with the RI and TCK with fixed functions matching
the SDO 2.1 specification?



Its also important to recognize that Apache is about community and projects
need a scope that is broad enough to foster a community.

To maintain an active community there needs to be something to keep
developers participating after the 2.1.1 RI is done, otherwise why even do
this at Apache?  If a goal is to continually extend the capabilities of SDO
and to feed innovation into future versions of specifications then thats
going to work better if there is a single SDO community not communities
split between separate Apache projects.


I agree that a sustainable project community would need something beyond
just doing the RI for SDO 2.1.1.  This could be to continue as an RI for
future SDO spec levels, or it could be to branch out in innovative ways
beyond any current or in-progress SDO specification.  I suspect that
trying to do both of these at the same time would be quite a stretch and
could lead to neither goal being achieved very well.  If the proposers of
the new project could indicate which of 

Re: Can a tuscany webservice call another?

[Simon Nash]

ernie mcginty wrote:

Hello,

I've created two tuscany webservices that work
independently but I would like for the one to be able
to call some of the methods/operations of the other. 
The examples I've seen show the wires fanning out from

a client such as the calculator or a jsp or a web
service component is wired to a java implementation
such as the currencyConvertor in the store example. 
How can I get a reference to work btwn two web

services? In the eclipse tool, my @Reference section
resolves and I'm able to write the necessary code.

?xml version=1.0 encoding=UTF-8?
composite   xmlns=http://www.osoa.org/xmlns/sca/1.0;
xmlns:t=http://tuscany.apache.org/xmlns/sca/1.0;
xmlns:c=http://battleship;
name=battleship
component name=wbl
t:implementation.resource location=web/
service name=Resource
t:binding.http/
/service
/component
component name=DataObjects
implementation.java
class=battleship.DataObjectsImpl/
service name=DataObjects
binding.ws uri=ws/
t:binding.jsonrpc uri=json/
/service
/component
component name=GamePlay
implementation.java
class=battleship.BattleshipGameImpl/
service name=BattleshipGame
binding.ws uri=ws/
t:binding.jsonrpc uri=json/
/service
reference name=dataObject target=DataObjects/
	/component   
/composite


Thanks in advance.


  

Never miss a thing.  Make Yahoo your home page. 
http://www.yahoo.com/r/hs


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



Hello, Ernie.  We have a few samples that show how to do this.
You can either define the reference and service using explicit WSDL
files, or you can let the Tuscany runtime generate these for you.

An example of the first style is helloworld-ws-reference, which talks
to a web service defined by helloworld-ws-service.  The reference's
binding.ws specifies a pre-generated WSDL file.

An example of the second style is calculator-ws-webapp, in which
neither the reference definition nor the service definition uses a
pre-generated WSDL file.

  Simon


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

Re: Problem with stateless (and stateful) Callback Service

[Simon Nash]

Simon Nash wrote:

Simon Laws wrote:

On Jan 23, 2008 11:23 AM, Simon Laws [EMAIL PROTECTED] wrote:


snip...


I have successfully created and tested stateless callback service with
webapp with Tuscany-1.0.
Now have a problem with Tuscnay-1.1-RC3..
My stateless service was deployed in Tomcat as a war(Tomcat was running
on
8080)
Now my problem is as below, i got following error on client side when i
try
to run my client(stateless callback)


- 





Hi Nishant

Can you say something more about the composites you are running and how
you are running them, for example, from the text above it appears 
that you

are running a client and a server.

server = Tomcat on port 8080
  composite
 component - a component providing a service that will callback 
to the

caller

client = Java application?
  composite
 component - a component that will talk to the server service and 
also

provide a callback service

I assume you are running both of these on the same machine.

Assuming that all of this is true and looking at the error trace I would
guess that what is happening is that the SCA runtime is trying to 
bring the
client callback service up on Jetty on port 8080, The same port that 
Tomcat

is already running on.

You could confirm this by starting Tomcat on a different port to see 
what

happens.

If this is the case then you could switch to the Node implementation 
will
will choose a free port so that this clash doesn't happen. Having 
said this
I seem to remember seeing a post about callback binding 
configuration. I'll
see if I can find it as it might provide a more straightforward 
solution.


Regards

Simon



Hi Nishant

Firstly did you get past your Net bind exception?

As a follow up to this. I've been trying a scenario that is similar to 
the

one you describe and experienced the same kind of problem. I tried first
with the default app container that we ship with 1.1 which is Jetty. When
this failed I went in and fully specified the URIs on the callback 
bindings
as well as the forward bindings. This still failed with Jetty on the 
client
side. However when I changed over to Tomcat on the client side it 
worked OK
and I see a forward message passing from client to the service running 
as a

webapp in Tomcat which in turn results in a callback passing back to the
client.

So another thing to try is host-tomcat in place of host-jetty for the 
client

application. The service is still deployed as a webapp in Tomcat.

Let me know how you get on.

Also it would be useful to have your scenario as a test case for future
release. Would you consider contributing it?

Regards

Simon


Sorry, I missed this the first time around.  Can you post more specific
details of the scenario (yours, not Nishant's) that fails with 1.1?
Is it based on one of the existing samples or itests?

  Simon


I have been trying to recreate the symptoms described by Nishant and
SimonL, but I have not been successful.

My service is packaged in a webapp deployed in Tomcat.  My client is
a J2SE client with an embedded web container for the callback.  Both
client and server are running in the same machine.

With the host.embedded API in the client, the client fails to start
because port 8080 is in use.  This happens with either Jetty or
Tomcat as the embedded client web container.

With the node API in the client, the forward and callback calls are
made OK.  This happens with either Jetty or Tomcat as the embedded
client web container.

In all cases, everything is working as I would expect.

  Simon


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

Re: Problem with stateless (and stateful) Callback Service

[Simon Nash]

Simon Laws wrote:

On Jan 23, 2008 11:23 AM, Simon Laws [EMAIL PROTECTED] wrote:


snip...


I have successfully created and tested stateless callback service with
webapp with Tuscany-1.0.
Now have a problem with Tuscnay-1.1-RC3..
My stateless service was deployed in Tomcat as a war(Tomcat was running
on
8080)
Now my problem is as below, i got following error on client side when i
try
to run my client(stateless callback)


-



Hi Nishant

Can you say something more about the composites you are running and how
you are running them, for example, from the text above it appears that you
are running a client and a server.

server = Tomcat on port 8080
  composite
 component - a component providing a service that will callback to the
caller

client = Java application?
  composite
 component - a component that will talk to the server service and also
provide a callback service

I assume you are running both of these on the same machine.

Assuming that all of this is true and looking at the error trace I would
guess that what is happening is that the SCA runtime is trying to bring the
client callback service up on Jetty on port 8080, The same port that Tomcat
is already running on.

You could confirm this by starting Tomcat on a different port to see what
happens.

If this is the case then you could switch to the Node implementation will
will choose a free port so that this clash doesn't happen. Having said this
I seem to remember seeing a post about callback binding configuration. I'll
see if I can find it as it might provide a more straightforward solution.

Regards

Simon



Hi Nishant

Firstly did you get past your Net bind exception?

As a follow up to this. I've been trying a scenario that is similar to the
one you describe and experienced the same kind of problem. I tried first
with the default app container that we ship with 1.1 which is Jetty. When
this failed I went in and fully specified the URIs on the callback bindings
as well as the forward bindings. This still failed with Jetty on the client
side. However when I changed over to Tomcat on the client side it worked OK
and I see a forward message passing from client to the service running as a
webapp in Tomcat which in turn results in a callback passing back to the
client.

So another thing to try is host-tomcat in place of host-jetty for the client
application. The service is still deployed as a webapp in Tomcat.

Let me know how you get on.

Also it would be useful to have your scenario as a test case for future
release. Would you consider contributing it?

Regards

Simon


Sorry, I missed this the first time around.  Can you post more specific
details of the scenario (yours, not Nishant's) that fails with 1.1?
Is it based on one of the existing samples or itests?

  Simon


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

Re: store example as a servlet?

[Simon Nash]

+1 for using implementation.web.

  Simon

Luciano Resende wrote:


+1, implementation.web would be good.

On Jan 15, 2008 6:34 PM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:


Matthew Peters wrote:


I have just been through the get started in 10 minutes and I like the
store example; it's small and neat. I was thinking of adapting it and
redoing it as a servlet, just to compare. I realise this is a backward
step in a way of course - instead of the AJAX style, back to page
refreshes, and running the code on the server. Nonetheless it would be
interesting to compare. Before I start, has anyone done it already?

Matthew Peters



That makes sense to me. You could define a new implementation.servlet
implementation type or try to implement the implementation.web
described at http://www.osoa.org/pages/viewpage.action?pageId=3980.

--
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: Eclipse RCP apps and Tuscany

[Simon Nash]

Simon Laws wrote:

Hi Rajini




But the code that I have run into problems with are in


org.apache.tuscany.sca.node.util.SCAContributionUtil.findContributionFromResource
(ClassLoader
classLoader, String compositeString)

which only works with file:// or jar:// URLs (it is very similar to the
code
used by the old DefaultSCADomain).




I've always been skeptical about this method. It was included as a
convenience to allow the location of a contribution to be determined from
some well know file, for example, the composite file that is being tested.
Handy for testing but it seems back to front to me. As a user you either
have a contribution or you don't. Seems a strange thing to ask a runtime to
find a contribution based on what is known to be inside it.




This method is invoked from

 1. SCADomainImpl to find the folder/jar containing domain.composite
 2. SCADomainProxyImpl to find the folder/jar containing node.composite
 3. SCANodeFactory.createNodeWithComposite(String composite)
 4. SCANodeLauncher.main()

1) and 2) in particular need to be fixed properly since they are internal
to





Tuscany and it doesn't seem appropriate to expect applications to
override resource loading for the Tuscany runtime when Tuscany is
installed
into OSGi.




For 1 and 2 I'm sure we can find a better solution that using this method,
for example, some alternatives
  Have the runtime implementations that Ant is thinking about specify a well
know location for these system contributions
  Have the assemblies for these contributions generated programatically
rather than read from the file system


Case 3 is a convenience method for use by samples and itests.  The
composite file may either be part of the current module and picked up
from the target/classes directory, or it may be part of some other
module that's listed in the pom.xml dependencies of the current module,
and picked up from a jar file in a local or remote maven repo.  The
findContributionFromResource() method allows these two cases to be
treated the same by the sample writer.

If we change the samples and tests so that they identify contributions
rather than composite files, I think we would also need to change the
build process to package contributions in a uniform way (probably as
jar files), so that case 3 could use a replacement convenience API
that refers explicitly to contributions rather than to composite files.

  Simon



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

Re: Eclipse RCP apps and Tuscany

[Simon Nash]

The SCADomain.newInstance() method and the DefaultSCADomain class in
host-embedded have been replaced by the domain and node APIs in
domain-api and node-api.  However, most samples have not yet been
converted to the new APIs.  For examples of samples that use the
new APIs, see callback-ws-client, callback-ws-service and
calculator-distributed.

Do the same issues apply to the new APIs, or only when the old
DefaultSCADomain class is used?

  Simon

Rajini Sivaram wrote:


SCADomain.newInstance(compositeName), which is used in many of the Tuscany
samples to create a DefaultSCADomain works only if
contextClassLoader.getResource(compositeName) returns a file:// or jar://
URL. This is broken when Tuscany is run under OSGi, since Apache Felix
returns a bundle:// URL and Equinox returns a bundleresource:// URL for the
composite. At the moment, existing samples can be run under an OSGi based
Tuscany only by using a custom classloader as the thread context
classloader, which returns file:// or jar:// URLs from its getResource
method, like Jason described(
http://marc.info/?l=tuscany-userm=119559170431301w=2).

DefaultSCADomain determines the location of the SCA contribution relative to
the composite or sca-contribution.xml. This file is first loaded using
applicationClassLoader.getResource(), and root of the contribution folder or
jar file  is determined from the resource URL. Since bundle:// URLs dont
correspond to a folder or jar file, they are not correctly processed by
Tuscany. To fix this in Tuscany, we need a BundleContributionProcessor
similar to JarContributionProcessor (at the moment, artifacts from bundle
contributions are read using the JarContributionProcessor). The bundle
contribution processor should either 1) read the stream using the bundle URL
and use OSGi bundle API to read its artifacts or 2) find the actual file
location corresponding to the bundle and read it using the
JarContributionProcessor. Unfortunately, both of these require OSGi specific
code in the contribution processing logic.

addContribution() methods for SCANode and SCADomain work with file:// URLs
which specify bundle contributions, and these are resolved correctly using
OSGi. But at the moment, they cannot process bundle:// URLs. A proper fix
for DefaultSCADomain will also enable bundle:// or bundleresource:// URLs to
be used in addContribution().

Since this is a problem only when Tuscany is run under OSGi, and any fix
would require adding OSGi specific code into the contribution processing
code in Tuscany, I am not sure if this needs fixing in Tuscany, or the
workaround of overriding the context classloader is sufficient.

Thoughts?




On 11/23/07, Peter Kriens [EMAIL PROTECTED] wrote:


I think it sounds very much like Felix Meschberger's conclusion.
Converting URLs to strings and then back to URLs, which is not
necessary and not guaranteed to work.

Anyway, I'd like to know why someone needs to escape to Equinox hooks
when it should work on standard OSGi level ...

Kind regards,

   Peter Kriens

RS Hi,

RS Tuscany supports OSGi bundle contributions which are currently loaded
using
RS the Apache Felix OSGi runtime by default. These contributions can
contain
RS composite files and other meta-data which are  loaded using OSGi and
RS passed around as URLs. Tests for OSGi contributions are run under
Felix with
RS urlhandlers set, so we dont have any trouble with bundle:// URLs
returned by
RS resources located using Felix (Tuscany calls openConnection and
openStream
RS on these urls).

RS Are the Eclipse RCP apps run without an URL stream handler to handle
RS bundleresource:// URLs?


RS Thank you...

RS Regards,

RS Rajini

RS On 11/23/07, Felix Meschberger [EMAIL PROTECTED] wrote:


Hi all,

I don't think it is a bug in eclipse (just from the likeliness point of
view). What I do not know is, what Tuscany does with the URLs returned.
If they would just open a stream on the URL, there would be no issue at
all, because the URls are backed by handlers supporting opening the
streams.

If on the other they convert the URls to Strings and later want to
create URLs from the strings again, they are hosed. But I assume, this
is then a bug/issue in Tuscany rather than in Eclipse. In fact, they
might run into the same troubles with Felix or just about any
framework...

Regards
Felix

Am Freitag, den 23.11.2007, 08:55 + schrieb Rob Walker:


Peter

On a  very quick read thru this - tbh - it sounds like a bug/feature


of


their OSGi implementation.

I'm 99% sure we use classloader getResource() calls under Felix, and


the


felix classloaders correctly resolve them to bundle URL references


which


can then be used in a normal way. Pretty sure you need the URL


handler


feature enabled, since I think as Jason points out the URL returned


has


a custom protocol type that the specific framework implementation


needs


to handle.

A possible alternative may be for them to use getResourceAsStream()


if


viable - since this will 

Re: Does Tuscany support jaxws implementation?

[Simon Nash]

See inline.

  Simon

Raymond Feng wrote:


Hi,

I'm looking into the JAXWS support from a slight different perspetive. 
Basically, I'm adding JAXWS annotation processing capability into 
Tuscany so that Tuscany can capture the addtional metadata from the 
annotations and use them during runtime.



+1 for adding this.  Is this only for JAX-WS annotations or for
JAXB annotations as well?

  Simon


Thanks,
Raymond

- Original Message - From: Denny Xu [EMAIL PROTECTED]
To: tuscany-user@ws.apache.org
Sent: Wednesday, January 02, 2008 12:24 AM
Subject: Does Tuscany support jaxws implementation?



Hi all

I create a web service using stp jaxws project,  and now, I want assembly
these services as using sca components, I wondered if Tuscany supports 
jaxws

service as its implementation. I am trying to create a sca component in
composite file by following MikeEdwards's article in OSOA which url is
http://www.osoa.org/display/Main/JAX-WS+Services+Integration.

component name=GreeterComponment
tuscany: implementation.jaxws class=
org.apache.hellow_world_soap.GreeterImpl/
/component

Does Tuscany know the tag implementation.jaxws

Thanks
Denny




-
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: Does Tuscany support jaxws implementation?

[Simon Nash]

Hi Denny,
It may be possible to create a POJO wrapper class for the jaxws service
and use the implementation.java type to make this into an SCA component.
If you can point me at an example jaxws service with instructions for
how to run it, I'll take a look and see how feasible this is.

  Simon

Denny Xu wrote:

Hi Simon

I would like to add support for implementation.jaxws components in Tuscany,
but for now , I have been working on Eclipse STP project and have to spent
more time on the project for next release. I'm very interested in Tuncany
and very pleasure to contribute to it when I have more time.

So far, in my project, I am trying to assemble jaxws services into SCA
components and run with tuncany,  do you have any suggestions on how to
create sca components with jaxws implementation?  where can I get a sample
about it?

Thanks
Denny




On Jan 2, 2008 7:42 PM, Simon Nash [EMAIL PROTECTED] wrote:



Hi Denny,
We don't have this support in Tuscany currently.  I think it would
be good to add it.

I have been doing some work recently to provide better support for
JAX-WS semantics in the Tuscany implementations of implementation.java
and binding.ws, but this is not the same as what's described in the
article.  However, this code should be reusable as part of the work
to support implementation.jaxws components.  For example, the fix for
TUSCANY-1939 adds data binding support for the default JAX-WS mapping
of thrown POJO exceptions.

Are you interested in helping with adding support for implementation.jaxws
components in Tuscany?

 Simon

Denny Xu wrote:


Hi all

I create a web service using stp jaxws project,  and now, I want


assembly


these services as using sca components, I wondered if Tuscany supports


jaxws


service as its implementation. I am trying to create a sca component in
composite file by following MikeEdwards's article in OSOA which url is
http://www.osoa.org/display/Main/JAX-WS+Services+Integration.

component name=GreeterComponment
tuscany: implementation.jaxws class=
org.apache.hellow_world_soap.GreeterImpl/
/component

Does Tuscany know the tag implementation.jaxws

Thanks
Denny




-
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: Does Tuscany support jaxws implementation?

[Simon Nash]

Hi Denny,
We don't have this support in Tuscany currently.  I think it would
be good to add it.

I have been doing some work recently to provide better support for
JAX-WS semantics in the Tuscany implementations of implementation.java
and binding.ws, but this is not the same as what's described in the
article.  However, this code should be reusable as part of the work
to support implementation.jaxws components.  For example, the fix for
TUSCANY-1939 adds data binding support for the default JAX-WS mapping
of thrown POJO exceptions.

Are you interested in helping with adding support for implementation.jaxws
components in Tuscany?

  Simon

Denny Xu wrote:

Hi all

I create a web service using stp jaxws project,  and now, I want assembly
these services as using sca components, I wondered if Tuscany supports jaxws
service as its implementation. I am trying to create a sca component in
composite file by following MikeEdwards's article in OSOA which url is
http://www.osoa.org/display/Main/JAX-WS+Services+Integration.

component name=GreeterComponment
tuscany: implementation.jaxws class=
org.apache.hellow_world_soap.GreeterImpl/
/component

Does Tuscany know the tag implementation.jaxws

Thanks
Denny




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

Re: web service problem (and configuration)

[Simon Nash]

I don't think you can pass or return an interface type across
the Web Service binding, only a class type.

This is a rather nasty limitation.  I believe there is some deep
JAXB magic (factory annotations) that could work around this
limitation, but I haven't got far enough into this to know how
to use it or whether it currently works in Tuscany.

  Simon

Mariano Kohan wrote:


hello,

this is an example that shows the problem.
listSalePointCodesOA and listSalePointCodesIA return an array and works
well, but listSalePointCodes return a List and have the commented
problems.They are defined in.Services and implemented in
ServicesImplementation.
Runner is the class that start the application.
The web services are published in http://localhost:8887/Services?wsdl.

thanks,
Mariano

Source classes:

package application.services.interfaces;

import java.rmi.Remote;
import java.rmi.RemoteException;
import java.util.List;

import org.osoa.sca.annotations.Remotable;


/**
 * @author Mariano Kohan
 * @version 1.0
 *
 */
@Remotable
public interface Services
extends Remote
{

//prueba de retorno de un listado con tipos basicos
public List listSalePointCodes() throws RemoteException, Exception;
//se prueba retornando un arreglo de objetos
public Object[] listSalePointCodesOA() throws RemoteException,
Exception;
//se prueba retornando un arreglo de objetos basicos
public Integer[] listSalePointCodesIA() throws RemoteException,
Exception;

}

import application.services.interfaces.Services;

//@Service(Services.class)
public class ServicesImplementation
implements Services
{

public ServicesImplementation()
throws RemoteException
{
}

public List listSalePointCodes() throws RemoteException, Exception {
//shows only the first and last elements
//List codes = new LinkedList();
//shows no elements
List codes = new ArrayList();
codes.add(new Integer(1));
codes.add(new Integer(2));
codes.add(new Integer(14));
codes.add(new Integer(61));
codes.add(new Integer(1));
codes.add(new Integer(8));
codes.add(new Integer(33));
return codes;
}

public Object[] listSalePointCodesOA() throws RemoteException, Exception
{
List codes = this.listSalePointCodes();
return codes.toArray();
}

public Integer[] listSalePointCodesIA() throws RemoteException,
Exception {
List codes = this.listSalePointCodes();
Integer[] codesArray = new Integer[codes.size()];
int i = 0;
for (Iterator iterator = codes.iterator(); iterator.hasNext();) {
Integer code = (Integer) iterator.next();
codesArray[i++] = code;
}
return codesArray;
}

}

package application.server;

import org.apache.tuscany.sca.host.embedded.SCADomain;

public class Runner {

public Runner(){

}

/**
 * inicializacion del dominio SCA
 */
public void initialize(String xmlFileNameString)
   throws Exception
 {

System.out.println(Starting of the SCA Application exposed as RMI
and Web Services ...);
SCADomain scaDomain = SCADomain.newInstance(xmlFileNameString);
System.out.println(... Press Enter to Exit...);
System.in.read();
scaDomain.close();
System.out.println(Exited...);
System.exit(0);

 }

public static void main(String[] args)
throws Exception
{
Runner applicationServicesRunner = new Runner();
applicationServicesRunner.initialize(args[0]);
}

}

Configuration Files:

-composite

composite xmlns=http://www.osoa.org/xmlns/sca/1.0;
xmlns:t=http://tuscany.apache.org/xmlns/sca/1.0;
targetNamespace=http://application;
name=application

component name=ApplicationServiceComponent
implementation.spring location=test.app\src\resource/
service name=Services type=
application.services.interfaces.Services
target=SERVICES
  binding.ws uri=http://localhost:8887/Services/
   /service

/component

-spring beans

?xml version=1.0 encoding=UTF-8?
beans xmlns=http://www.springframework.org/schema/beans;
   xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
   xmlns:sca=http://www.springframework.org/schema/sca;
   xsi:schemaLocation=
   http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd
   http://www.springframework.org/schema/sca
http://www.springframework.org/schema/sca/spring-sca.xsd;

sca:service name=Services
type=application.services.interfaces.Services target=SERVICES/

!-- services --
bean id=SERVICES
class=application.services.implementation.ServicesImplementation
/bean

/beans

2007/12/20, Simon Laws [EMAIL PROTECTED]:


On Dec 20, 2007 5:44 PM, Mariano Kohan [EMAIL PROTECTED] wrote:



hello,

I have a problem when I expose a service with ws 

Re: Service Discovery for SCA

[Simon Nash]

I agree that this would be useful.  The place to enable it would be the
SCA Domain.  The Domain doesn't currently have APIs to list or search
for services.   We could add APIs that do this, or we could add an SPI
that allows a registry to plug in to the Domain and be informed whenever
services are added or removed.  The latter seems better to me, as it
would be easier to keep the registry in sync with the Domain.  I'd be
interested in other views on this.

  Simon

Miroslav Novak wrote:

Hi,
 SCA allows to describe components (services) in a standard way. It would be
nice to expose this information so that it can be automatically discovered
and stored in a repository. Later, when developers are about to create a new
component, they can search existing SCA components that they could reuse.

Do you plan to expose definition of SCA components via some API?

Regards,

Mirek


__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
__


-
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: SCA: OSOA Compliant Implementation?

[Simon Nash]

This has come up for discussion previously on the [EMAIL PROTECTED] list
(see [1]).  The conclusion was that this clause in the OSOA license
should not be a concern for Tuscany's implementation of SCA 1.0.

  Simon

[1] 
http://mail-archives.apache.org/mod_mbox/incubator-general/200709.mbox/[EMAIL 
PROTECTED]

Barb Cochrane wrote:


I have a quick question I hope one of the Apache team can help me with:  is
Tuscany's SCA 1.0 API a compliant implementation of OSOA's Service Component
Architecture Specification?  I'm asking because of the OSOA SCA Spec license
terms.  


Thanks in advance!

Cheers,

Barb


-
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: Promoting the service using both ws rmi

[Simon Nash]

ashjk wrote:


1. Can we promote the same service using both ws  rmi bindings?


Yes, this should work.


2. I have a scenario where I am using a callback ws which has to be accessed
by two clients, one is callback client and other is just accessing some
methods. I had tried adding the operations in the same wsdl but it was not
working as the server is not responding for both the clients.


Can you try this without specifying any WSDL?  The ws-callback-client and
ws-callback-service samples show how to do this.

  Simon



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

Re: SCA WS Binding Wrapper Style

[Simon Nash]

Jean-Sebastien Delfino wrote:


Simon Laws wrote:
[snip]



The assumption I'm making from the info you gave is that you want to have
two SCA components communicate with the same domain but be able to 
specify
the WSDL that the web services binding uses.  I guess what you would 
need to

be able to do is specify a binding something like

component name=MyClientComponent
implementation.java class=org.apache.tuscany.SomeImpl/
reference name=myService 
target=MyServiceComponent/MyService

   binding.ws wsdlElement=
http://tuscany.apache.org#wsdl.binding(MyServiceSOAP11Binding)/
/reference
etc..

Where you are referencing a WSDL binding but not providing a service
location with a view to having the domain sort this out for you. A 
similar

thing would appear on the service end also.

This all sounds plausible but I just took a look at the SCA WebServices
binding specification and it says that when the #wsdl.binding form is 
used

the endpoint address URI must be provided via the URI attribute on the
binding which makes it a little difficult for the domain logic to help 
you

out. There is a possibility that this is a fault in the spec in this case
but let me try a few experiments and think about it a little before we 
call

it out. If others know the answer now feel free to jump in.



My understanding is that wiring is not limited to the SCA binding. It's 
probably a bug in the WS binding spec, which should allow the WS 
endpoint address to be determined through wiring in the domain.


In other words the above XML snippet should be made to work.


+1.  I have raised a spec issue with the SCA bindings TC for this.

  Simon



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

Re: SCA WS Binding Wrapper Style

[Simon Nash]

I have been looking at the JAX-WS and JAXB specs and I think it
should be possible to pass nulls when using the default Java to
XML mapping.  Can you open a JIRA and attach a test case that
shows the problem you are having with this?

  Simon

Bentley Johnson wrote:

Simon, 

Yes, it requires the removal of overloaded methods and I also have to change 
any java objects to be in a javabean format. Although, this would have to be 
done either way. Our system had some code which was not conformed to 
javabean style and since we are now converting to use Tuscany, it must be 
updated for the java object creation by tuscany.  I had thought that the 
non-void return type was an issue, but I tried the sample mentioned in the 
previous response and think it should work just fine.


There is also a different issue that I have discovered and was going to post 
about, but I was trying to check the old mailing lists first. I did not find 
it mentioned there. It seems that the the Transformer classes for converting 
to and from XML for both simple and javabean styled objects does not handle 
the inclusion of null values.  This includes both passing in a null as a 
parameter or returning null from a method.  Is this a desired/required 
situation that nulls can not be used? or is it a flaw in the conversion. The 
one exception where null values do process correctly are null Strings.  If 
this is a requirement, then I would also have to change logic in my system 
to work around not being able to use null values. This may be problematic. 


Thanks, Bentley



-Original Message-

From: Simon Nash [EMAIL PROTECTED]

To: tuscany-user@ws.apache.org

Date: Mon, 26 Nov 2007 21:56:55 +

Subject: Re: SCA  WS Binding Wrapper Style




Bentley,

What modifications are needed to your code to make it conform to the

doc/lit/wrapped standard?  Is this just the removal of overloaded

nethod names, or something else?



   Simon



Bentley Johnson wrote:





Hello, thanks for the response and input.




One thing I realized was that I didn't make clear in my original post was 



that I am working with the distributed domain/node system which seems to 


use 



only the SCA binding by default with the Remotable annotation. This does 


not 



allow me to use the WSDL configurations. This  assumption is based on the  





sample distributed code and  testing I have attempted.




Using the default SCA binding of that configuration seems to always use 


the 



wrapper (document/literal) mode. This is not a large issue, as my code can 




be modified to conform to its standards. If there is some other way to 


have 



the services register within the domain that I have not seen, that 




information would be appreciated.





Thanks





Bentley





-Original Message-





From: Simon Laws [EMAIL PROTECTED]





To: tuscany-user@ws.apache.org





Date: Thu, 22 Nov 2007 11:28:24 +





Subject: Re: SCA  WS Binding Wrapper Style








Hi Bentley







Some comments/questions below







Regards







Simon






On Nov 21, 2007 7:04 PM, Bentley Johnson [EMAIL PROTECTED] 


wrote:







It seems that both the default SCA binding for Remotable Interfaces and






the






basic WS binding are being restricted to the services following the






wrapper








It certainly use doc/lit/wrapped by default and WSDL generated by Tuscany




Java2WSDL will use this style.  The SCA WebService spec says that, when 


the




web services binding points to separately authored WSDL files, it allows





anything that is valid in the WSDL binding. I can't guarantee that this





actually works at the moment as I would need to try it but the





specifications intention is that it is supported.









style. This is being set within the






org.apache.tuscany.sca.binding.ws.axis2.Java2WSDLHelper class in the






createWSDLInterfaceContract method. From my understanding, this implies






that






all methods in the service must have a return type that is not void and






that







You should be able to have a void return type. There is an itest that 


shows




an example (




http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/itest/ws-void-args-return/ 
[http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/itest/ws-void-args-return/] 




[http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/itest/ws-void-args-return/ 
[http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/itest/ws-void-args-return/]]





)









overloaded methods are not allowed.








Do you mean WSDL operations with the same name but with different





parameters?









Is there a way to set it to not use the wrapper style or is it just the






standard that is used by the SCA binding and must be followed?








I think the intention is that any web services communications that go on




under Tuscany's control, e.g. where the remote version of the SCA binding 


is



in use, choose

Re: SCA WS Binding Wrapper Style

[Simon Nash]

Either the original class name would have to be passed on the
wire by the sender, or the receiver would have to tell the Tuscany
databinding framework what class to use for each interface type
that's received.  The former isn't very interoperable (e.g., if
talking to a non-Java environment), and the latter couldn't cope
with multiple classes being passed through the same interface.

I am sure JAXB has some solution to this, but it wasn't revealed
by a casual glance through the spec.  I'll try harder to find this
information.  Can anyone else provde a pointer?

  Simon

Bentley Johnson wrote:

I found another modification that will have to be done, unless there is 
alternative, however, this may be related to Javabeans being used for object 
serialization. In many instances, the parameters or return types of our 
service methods are java interfaces and there are implementations of these 
interfaces being created and used. When the XML is created for sending over 
the binding, it attempts to use the interface as the java class that must be 
created on the receiving end. The reflection being used can of course not 
create an instance of the interface and it throws an exception. Is there any 
way to specific for it to use the actual class implementation when converted 
to and from XML?  


Thanks, Bentley

-Original Message-

From: Simon Nash [EMAIL PROTECTED]

To: tuscany-user@ws.apache.org

Date: Mon, 26 Nov 2007 21:56:55 +

Subject: Re: SCA  WS Binding Wrapper Style




Bentley,

What modifications are needed to your code to make it conform to the

doc/lit/wrapped standard?  Is this just the removal of overloaded

nethod names, or something else?



   Simon



Bentley Johnson wrote:





Hello, thanks for the response and input.




One thing I realized was that I didn't make clear in my original post was 



that I am working with the distributed domain/node system which seems to 


use 



only the SCA binding by default with the Remotable annotation. This does 


not 



allow me to use the WSDL configurations. This  assumption is based on the  





sample distributed code and  testing I have attempted.




Using the default SCA binding of that configuration seems to always use 


the 



wrapper (document/literal) mode. This is not a large issue, as my code can 




be modified to conform to its standards. If there is some other way to 


have 



the services register within the domain that I have not seen, that 




information would be appreciated.





Thanks





Bentley





-Original Message-





From: Simon Laws [EMAIL PROTECTED]





To: tuscany-user@ws.apache.org





Date: Thu, 22 Nov 2007 11:28:24 +





Subject: Re: SCA  WS Binding Wrapper Style








Hi Bentley







Some comments/questions below







Regards







Simon






On Nov 21, 2007 7:04 PM, Bentley Johnson [EMAIL PROTECTED] 


wrote:







It seems that both the default SCA binding for Remotable Interfaces and






the






basic WS binding are being restricted to the services following the






wrapper








It certainly use doc/lit/wrapped by default and WSDL generated by Tuscany




Java2WSDL will use this style.  The SCA WebService spec says that, when 


the




web services binding points to separately authored WSDL files, it allows





anything that is valid in the WSDL binding. I can't guarantee that this





actually works at the moment as I would need to try it but the





specifications intention is that it is supported.









style. This is being set within the






org.apache.tuscany.sca.binding.ws.axis2.Java2WSDLHelper class in the






createWSDLInterfaceContract method. From my understanding, this implies






that






all methods in the service must have a return type that is not void and






that







You should be able to have a void return type. There is an itest that 


shows




an example (




http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/itest/ws-void-args-return/ 
[http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/itest/ws-void-args-return/] 




[http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/itest/ws-void-args-return/ 
[http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/itest/ws-void-args-return/]]





)









overloaded methods are not allowed.








Do you mean WSDL operations with the same name but with different





parameters?









Is there a way to set it to not use the wrapper style or is it just the






standard that is used by the SCA binding and must be followed?








I think the intention is that any web services communications that go on




under Tuscany's control, e.g. where the remote version of the SCA binding 


is



in use, choose the doc/lit/wrapped style and stick with that. If 


alternative




styles are required then this would be configured using a





separately/manually authored WSDL to describe what style is required.  I




would imagine this would very

Re: SCA WS Binding Wrapper Style

[Simon Nash]

Bentley,
What modifications are needed to your code to make it conform to the
doc/lit/wrapped standard?  Is this just the removal of overloaded
nethod names, or something else?

  Simon

Bentley Johnson wrote:


Hello, thanks for the response and input.

One thing I realized was that I didn't make clear in my original post was 
that I am working with the distributed domain/node system which seems to use 
only the SCA binding by default with the Remotable annotation. This does not 
allow me to use the WSDL configurations. This  assumption is based on the  
sample distributed code and  testing I have attempted.


Using the default SCA binding of that configuration seems to always use the 
wrapper (document/literal) mode. This is not a large issue, as my code can 
be modified to conform to its standards. If there is some other way to have 
the services register within the domain that I have not seen, that 
information would be appreciated.


Thanks

Bentley

-Original Message-

From: Simon Laws [EMAIL PROTECTED]

To: tuscany-user@ws.apache.org

Date: Thu, 22 Nov 2007 11:28:24 +

Subject: Re: SCA  WS Binding Wrapper Style




Hi Bentley



Some comments/questions below



Regards



Simon



On Nov 21, 2007 7:04 PM, Bentley Johnson [EMAIL PROTECTED] wrote:





It seems that both the default SCA binding for Remotable Interfaces and




the




basic WS binding are being restricted to the services following the




wrapper





It certainly use doc/lit/wrapped by default and WSDL generated by Tuscany

Java2WSDL will use this style.  The SCA WebService spec says that, when the

web services binding points to separately authored WSDL files, it allows

anything that is valid in the WSDL binding. I can't guarantee that this

actually works at the moment as I would need to try it but the

specifications intention is that it is supported.






style. This is being set within the




org.apache.tuscany.sca.binding.ws.axis2.Java2WSDLHelper class in the




createWSDLInterfaceContract method. From my understanding, this implies




that




all methods in the service must have a return type that is not void and




that





You should be able to have a void return type. There is an itest that shows

an example (

http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/itest/ws-void-args-return/ 
[http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/itest/ws-void-args-return/]


)






overloaded methods are not allowed.





 Do you mean WSDL operations with the same name but with different

parameters?






Is there a way to set it to not use the wrapper style or is it just the




standard that is used by the SCA binding and must be followed?





I think the intention is that any web services communications that go on

under Tuscany's control, e.g. where the remote version of the SCA binding is

in use, choose the doc/lit/wrapped style and stick with that. If alternative

styles are required then this would be configured using a

separately/manually authored WSDL to describe what style is required.  I

would imagine this would very likely to be the case if SCA is configured to

talk to web services that are provided by other, non-SCA, systems. Here you

would expect to be able to get the WSDL from the service provided. Do you

have a scenario that requires the use of something other than the

doc/lit/wrapped style in the case that one SCA component is talking to

another SCA component with the same domain?







Thanks





-Bentley






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

Re: Reg: callback

[Simon Nash]

This scenario whould work OK.  Can you post a stack trace for the
NullPointerException and the code for your application?

  Simon

ashjk wrote:


Hello,

I am using callback in my use-case, the scenario is that the callback should
happen (to the client) only after the approval from an approver. As I could
see from the samples that the flow is streamlined, I had tried out a sample
separating the service  client as different composites but it is not
working as it is throwing some NullPointer Exception while invocation, I
would be grateful if anyone would like to help me in this regard.

Thanks  Regards,
Ashwini Kumar J





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

Re: SOAPProcessingException after update from SCA 0.99 to 1.0

[Simon Nash]

Philipp,
Thanks for this information.  There are two problems here.

1. The WS-Addressing To header should not be added unless callbacks
   or conversations are in use.  Your test does not use callbacks
   or conversations, so this header should not be present.

2. The format of the WS-Addressing To header is wrong.  This is a
   known problem in Tuscany SCA Java 1.0 and 1.0.1: see TUSCANY-1849.

Axis2/C is trying to parse the WS-Addressing header according to
the WS-Addressing spec.  Because the header format is wrong, this
parsing fails and you get the error message.

I don't think there is any workaround.  We need to fix TUSCANY-1849
urgently to resolve this problem.  As part of this fix, we should also
avoid sending WS-Addressing headers unless they are needed for callbacks
or conversations.

  Simon

Simon Laws wrote:


On Nov 14, 2007 12:26 PM, Philipp Konradi [EMAIL PROTECTED] wrote:



Hi,

thank you guys very much for taking this issue on.
I've done tcpmonitoring as suggested and I noticed that the 1.0 runtime
was
sending additionally a Header with some Address element.

Here the SOAP-Message send from 1.0 runtime:
POST /axis2/services/HelloWorldComponent/HelloWorldService HTTP/1.1
  Content-Type: text/xml; charset=UTF-8
  SOAPAction: HelloWorldService#getGreetings
  User-Agent: Axis2
  Host: localhost:9090
  Content-Length: 508
?xml version='1.0' encoding='UTF-8'?
soapenv:Envelope
  xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/;
  soapenv:Header
  To xmlns=http://www.w3.org/2005/08/addressing;
  wsa:Address
  xmlns:wsa=
http://www.w3.org/2005/08/addressing;

http://localhost:9090/axis2/services/HelloWorldComponent/HelloWorldService
  /wsa:Address
  /To
  /soapenv:Header
  soapenv:Body
  _ns_:getGreetings xmlns:_ns_=http://sample/helloworld;
  _ns_:param1World/_ns_:param1
  /_ns_:getGreetings
  /soapenv:Body
/soapenv:Envelope


Here the SOAP-Message send from 0.99 runtime:
POST /axis2/services/HelloWorldComponent/HelloWorldService HTTP/1.1
  Content-Type: text/xml; charset=UTF-8
  SOAPAction: HelloWorldService#getGreetings
  User-Agent: Axis2
  Host: localhost:9090
  Content-Length: 271
?xml version='1.0' encoding='UTF-8'?
soapenv:Envelope
  xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/;
  soapenv:Body
  _ns_:getGreetings xmlns:_ns_=http://sample/helloworld;
  _ns_:param1World/_ns_:param1
  /_ns_:getGreetings
  /soapenv:Body
/soapenv:Envelope


Here the SOAP-Message send from Eclipse Web Service Explorer:
POST
http://localhost:9090/axis2/services/HelloWorldComponent/HelloWorldService
  HTTP/1.1
  Host: localhost:9090
  Content-Type: text/xml; charset=utf-8
  Content-Length: 337
  Accept: application/soap+xml, application/dime, multipart/related,
text/*
  User-Agent: IBM Web Services Explorer
  Cache-Control: no-cache
  Pragma: no-cache
  SOAPAction: HelloWorldService#getGreetings
  Connection: close
soapenv:Envelope
  xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/; xmln
  s:q0=http://sample/helloworld;
  xmlns:xsd=http://www.w3.org/2001/XMLSchema; xml
  ns:xsi=http://www.w3.org/2001/XMLSchema-instance;
  soapenv:Body
  q0:getGreetings
  q0:param1ghdfzh/q0:param1
  /q0:getGreetings
  /soapenv:Body
/soapenv:Envelope


For me it looks like the soap-header is causing the problem.
What do you think?
Could ws-binding configured in a way not to add the header to the SOAP
message?

Thanks,
Philipp





-Ursprüngliche Nachricht-
Von: Simon Nash [mailto:[EMAIL PROTECTED]
Gesendet: Dienstag, 13. November 2007 12:32
An: tuscany-user@ws.apache.org
Betreff: Re: SOAPProcessingException after update from SCA 0.99 to 1.0

I can think of a few changes between 0.99 and 1.0 that could affect
interoperability, but I don't think any of these would come into
play for the scenario described here.

For dynamically generated WSDL, a few changes were made to the
generation algorithm that affect methods with no arguments and/or
a void result.  However, the helloworld-ws-reference sample uses
statically created WSDL, not dynamically generated WSDL.

For callbacks and conversations, the wire protocol used to pass the
necessary information over Web services changed between 0.99 and 1.0.
However, the helloworld-ws-reference sample does not use callbacks
or conversations.

This error seems to indicate that the Axis2/C service received a
SOAP request containing some unexpected XML data.  Can you run with
a TCP monitor and post the SOAP messages that are being exchanged?

 Simon Nash

Simon Laws wrote:



On Nov 11, 2007 4:52 PM, Philipp Konradi [EMAIL PROTECTED] wrote:




Hi all,

after upgrading from Tuscany SCA Java v0.99 to 1.0 one

Re: At ApacheCon this week

[Simon Nash]

I'm at ApacheCon as well.  Please drop me email if you're going
to be around and would like to meet up.

  Simon

Jean-Sebastien Delfino wrote:

Anyone going to ApacheCon?

I'm there at the Hackathon today and will be there all week.

Drop me an email if you're going to be there and want to meet!




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

Re: SOAPProcessingException after update from SCA 0.99 to 1.0

[Simon Nash]

I can think of a few changes between 0.99 and 1.0 that could affect
interoperability, but I don't think any of these would come into
play for the scenario described here.

For dynamically generated WSDL, a few changes were made to the
generation algorithm that affect methods with no arguments and/or
a void result.  However, the helloworld-ws-reference sample uses
statically created WSDL, not dynamically generated WSDL.

For callbacks and conversations, the wire protocol used to pass the
necessary information over Web services changed between 0.99 and 1.0.
However, the helloworld-ws-reference sample does not use callbacks
or conversations.

This error seems to indicate that the Axis2/C service received a
SOAP request containing some unexpected XML data.  Can you run with
a TCP monitor and post the SOAP messages that are being exchanged?

  Simon Nash

Simon Laws wrote:


On Nov 11, 2007 4:52 PM, Philipp Konradi [EMAIL PROTECTED] wrote:



Hi all,

after upgrading from Tuscany SCA Java v0.99 to 1.0 one of my sample
applications has broken.
The app is pretty simple: a Java SCA service calls a Native SCA service
via
Web Services.
After version upgrade I'm getting a SOAPProcessingException saying Only
Characters are allowed here.

Does somebody else experienced something similar? Any explanations what's
the reason and how to fix/workaround here?

Here some details to the app:
The Java SCA service is actually the helloworld-ws-reference sample.
The Native SCA service is a simple helloworld implementation in C++
deployed
in Axis2/C.

The call makes it actually to Axis2/C but then Axis2/C returns a SOAP
fault
message.

Here the axis2c log:

[Sun Nov 11 16:07:29 2007] [info] Starting HTTP server thread
[Sun Nov 11 16:12:34 2007] [debug]
..\..\modules\core\transport\http\http_worker.c(206) Client HTTP version
HTTP/1.1
[Sun Nov 11 16:12:34 2007] [debug]
..\..\axiom\src\soap\soap_builder.c(868)
Identified soap version is soap11
[Sun Nov 11 16:12:34 2007] [debug] ..\..\modules\core\engine\engine.c(776)
Invoking phase TransportIn
[Sun Nov 11 16:12:34 2007] [debug] ..\..\modules\core\engine\phase.c(358)
Invoke the handler request_uri_based_dispatcher within the phase
TransportIn
[Sun Nov 11 16:12:34 2007] [debug]
..\..\modules\core\engine\req_uri_disp.c(104) Checking for service using
target endpoint address : http://127.0.0.1:9090/HelloWorldService
[Sun Nov 11 16:12:34 2007] [debug] ..\..\modules\core\engine\engine.c(776)
Invoking phase PreDispatch
[Sun Nov 11 16:12:34 2007] [debug] ..\..\modules\core\engine\phase.c(358)
Invoke the handler AddressingInHandler within the phase PreDispatch
[Sun Nov 11 16:12:34 2007] [info] Starting addressing in handler .
[Sun Nov 11 16:12:34 2007] [debug]
..\..\axiom\src\soap\soap_fault_code.c(273) trying to set fault subcode to
fault code more than once
[Sun Nov 11 16:12:34 2007] [debug] ..\..\modules\core\engine\engine.c(776)
Invoking phase MessageOut
[Sun Nov 11 16:12:34 2007] [debug] ..\..\modules\core\engine\phase.c(358)
Invoke the handler AddressingOutHandler within the phase MessageOut
[Sun Nov 11 16:12:34 2007] [info] Request served successfully

Here the output on the Java side:
[java] Injected helloWorldService
[java] Called getGreetings
[java] Exception in thread main
org.apache.axiom.soap.SOAPProcessingException: Only Characters are allowed
here
[java] at
org.apache.axiom.soap.impl.builder.SOAP11BuilderHelper.processText
(SOAP11BuilderHelper.java:151)
[java] at
org.apache.axiom.soap.impl.builder.SOAP11BuilderHelper.handleEvent
(SOAP11BuilderHelper.java:63)
[java] at
org.apache.axiom.soap.impl.builder.StAXSOAPModelBuilder.constructNode(
StAXSOAPModelBuilder.java:344)
[java] at
org.apache.axiom.soap.impl.builder.StAXSOAPModelBuilder.createOMElement(
StAXSOAPModelBuilder.java:187)
[java] at org.apache.axiom.om.impl.builder.StAXOMBuilder.next(
StAXOMBuilder.java:163)
[java] at org.apache.axiom.om.impl.llom.OMElementImpl.buildNext(
OMElementImpl.java:552)
[java] at org.apache.axiom.om.impl.llom.OMElementImpl.getFirstOMChild(
OMElementImpl.java:563)
[java] at
org.apache.axiom.om.impl.llom.OMElementImpl.getFirstChildWithName(
OMElementImpl.java:219)
[java] at org.apache.axiom.soap.impl.llom.soap11.SOAP11FaultImpl.getCode(
SOAP11FaultImpl.java:129)
[java] at org.apache.axis2.AxisFault.initializeValues(AxisFault.java:189)
[java] at org.apache.axis2.AxisFault.init(AxisFault.java:183)
[java] at org.apache.axis2.util.Utils.getInboundFaultFromMessageContext(
Utils.java:486)
[java] at
org.apache.axis2.description.OutInAxisOperationClient.handleResponse(
OutInAxisOperation.java:343)
[java] at org.apache.axis2.description.OutInAxisOperationClient.send(
OutInAxisOperation.java:389)
[java] at
org.apache.axis2.description.OutInAxisOperationClient.executeImpl(
OutInAxisOperation.java:211)
[java] at org.apache.axis2.client.OperationClient.execute(
OperationClient.java:163)
[java] at
org.apache.tuscany.sca.binding.ws.axis2.Axis2BindingInvoker.invokeTarget(
Axis2BindingInvoker.java

Re: Callback Service problem

[Simon Nash]

Nishant Joshi wrote:


Thanks for reply, I have generated wsdl by modifying composite file as you
have suggested, Now i have two wsdl generated on my Tomcat you can see the
log below

INFO: initContextPath: /sample-simple-callback-ws
Oct 25, 2007 10:35:24 AM
org.apache.tuscany.sca.host.webapp.WebAppServletHost addServletMapping
INFO: addServletMapping: /MyClientComponent
Oct 25, 2007 10:35:24 AM
org.apache.tuscany.sca.host.webapp.WebAppServletHost addServletMapping
INFO: addServletMapping: /MyServiceComponent
Now i want to understand how callback service work from client side. I m
creating client in Eclipse which was non-Tuscany client means i m using
eclipse's facility to create web services client.
So how i get callback facility in my cleint?


This isn't possible.  Callbacks require extra information to be passed
on the wire.  Currently only Tuscany can send and receive this extra
information.  The extra information is:
  (mandatory) callback URI, so the service knows where to direct the
 callback request
  (optional) application-specified callback ID, used by the application
 to correlate callbacks with the related application state
  (optional) conversation ID, used by Tuscany to correlate forward
 calls and callbacks with the related application state


Meanwhile i have created one sample in which i have used polling mechanism
to get result. So i want to understand how callback facility work i have
read somewhere that we need server on client side to get result from service
in callback, is it so?


Here's the end-to-end flow for a callback between a Tuscany client and
a Tuscany service.
 1. Client exposes a callback URI for the reference that is making
the call to the service.  You can think of this as turning the
reference into a callback service.
 2. Client makes a call to the service, passing the necessary callback
information.
 3. Service receives the call with the callback information.
 4. Service uses the callback information to make a callback to the
client URI exposed in step 1.

If the client is a non-Tuscany Web service client, then steps 1 and 2
don't happen.  This is why you are getting an error from step 4.


I have also seen the axis2 client they have also used callback plus polling
mechanism so i m bit confused about callback and polling mechanism.


Axis2 callbacks aren't the same as Tuscany callbacks.  In Axis2, a
callback tells the client that the forward service invocation has
completed.  In SCA and Tuscany, a callback is a separate service
invocation that can occur either before or after the forward call
has completed.


Is it mandatory to use @OneWay method in callback service? means one method
is of type void(@OneWay) and other method gives me the result which i have
done in polling


Callbacks can be used with or without @OneWay on either or both of the
forward call and the callback call.


Is it necessary to use polling mechanism with callback service to get
result?if not than using only callback how i get result?can you provide me
one sample client with only callback facility?


If a Tuscany client is talking to a Tuscany service, there is no need
to ever use polling, because a callback can be used instead.  You can
use a callback to send a result from a forward call if you want to,
or for any other application-specific purpose.  Here are two
examples showing both styles of using callbacks:

 1. A client makes an order call.  The response to the call informs
the client that the order is out of stock.  Some time later,
a callback is made to inform the client of the item's expected
availability date.  Later still, another callback informs the
client that the item is available.

 2. A client makes an order call.  No response is sent (the method
has void return type).  A callback is made saying that the order
is out of stock.

In the second case, the callback carries the response from the forward
call.  In the first case, there is a response from the forward call
and also some callbacks with additional information.

If the client placing the order is a non-Tuscany Web service client,
then it would need to either use polling or define its own callback
protocol that doesn't use SCA callbacks.


Sorry to ask you so much question but i m not able to clarify myself by
searching on net  :)
It will be very helpful if you can clarify my confusion.


No problem!  There is no documentation on this yet (I need to write
some :-)  I am very happy to answer any more questions that you have.

  Simon



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

Re: Callback Service problem

[Simon Nash]

Sorry for the delay in responding.  I took the simple-callback-ws
sample and modified it to use dynamically generated WSDL.  Here's
the simplecallback.composite file that I used:

composite xmlns=http://www.osoa.org/xmlns/sca/1.0;
targetNamespace=http://simplecallback;
xmlns:cb=http://simplecallback;
name=simplecallback

component name=MyClientComponent
implementation.java class=simplecallback.MyClientImpl /

reference name=myService
interface.java interface=simplecallback.MyService
callbackInterface=simplecallback.MyServiceCallback /
binding.ws uri=http://localhost:8085/MyServiceComponent; /
callback
binding.ws /
/callback
/reference
/component

component name=MyServiceComponent
implementation.java class=simplecallback.MyServiceImpl /

service name=MyService
interface.java interface=simplecallback.MyService
callbackInterface=simplecallback.MyServiceCallback /
binding.ws /
callback
binding.ws /
/callback
/service
/component
/composite

This works fine for me on the 1.0 level of code.

Looking at your .composite file, I have two comments/questions:

1. Your service doesn't include the callback element specifying
   the use of Web services for the callback.  You need to add this.
2. You have a service but no reference.  Where is the reference?
   How are you calling this service?

  Simon

Nishant Joshi wrote:

Hi All,
I have deployed one simple stateless callback service i have generated wsdl
on the fly with this service. When i am invoking client following error was
thrown.

RuntimeException invoking getResult: org.osoa.sca.ServiceRuntimeException:
No callback wire found for /
org.osoa.sca.ServiceRuntimeException: No callback wire found for /
 at
org.apache.tuscany.sca.core.invocation.JDKCallbackInvocationHandler.invoke(
JDKCallbackInvocationHandler.java:63)


I have one simple method which return string and also get string as
argument.
In simple-callback-ws example there is wsdl is already given so i m confused
about my composite file my composite file is as below


composite xmlns=http://www.osoa.org/xmlns/sca/1.0;
 targetNamespace=http://soa/examples;
 xmlns:hw=http://soa/examples; name=sample


 component name=ServiceComponent
  implementation.java
   class=my.example.MyServiceImpl /
  service name=MyService
   interface.java
interface=my.example.MyService
callbackInterface=my.example.MyServiceCallback /
   binding.ws /
  /service
 /component

/composite


can anybody help in this case?





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

Re: Callback Service problem

[Simon Nash]

The callback service appears in a separate WSDL from the forward service.
For the simple-callback-ws example that I converted to use dynamically
generated WSDL, the dynamically generated callback WSDL is available at
  http://localhost:8085/MyClientComponent?wsdl

The service name for the callback is myService but this does not appear
in the above URI because of the SCA rule that components with a single
service have URIs that don't include the service name.  The component
MyClientComponent has a single callback service myService.

  Simon

Nishant Joshi wrote:


I want to add something more in this topic that, I have generated wsdl on
the fly but i can't see callback service method in the wsdl as it was there
in sample simple-callback-ws.

So is it possible to generated wsdl on the fly with callback service methods
in wsdl? Is it necessary that callback service method be there in wsdl?





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

Re: tuscany asynchronous web service call

[Simon Nash]

To use @OneWay you must have a void return type and no exceptions.
The meaning of @OneWay is that there will never be any response
from the operation and the client does not need to wait for the
operation to complete.  If there is a non-void return type or any
declared exceptions then there will be (or may be) a response
from the operation, so you cannot use @OneWay.  SCA does not
permit these responses being thrown away without being delivered
back to the caller.

I tried using @OneWay on a method with a String return type and I
got a NullPointerException, like this:
 Exception in thread Axis2 Task java.lang.NullPointerException
 at 
org.apache.axis2.description.OutInAxisOperationClient$NonBlockingInvo
 cationWorker.run(OutInAxisOperation.java:444)
 at 
edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Wor
 ker.runTask(ThreadPoolExecutor.java:665)
 at 
edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Wor
 ker.run(ThreadPoolExecutor.java:690)
 at java.lang.Thread.run(Thread.java:595)

This is a bug!  We should produce a better exception to tell the user
what he/she has done wrong.  I opened TUSCANY-1867 for this.

I am not quite sure what you are trying to accomplish by using @OneWay
with a String return type.  Do you want the response to be thrown away
and the client to continue execution in parallel with the service method?
If so, you could achieve this by creating a wrapper method on the
client-side service with void return type and @OneWay.  This wrapper
method would call the two-way remote method.

I modified the simple-callback-ws code to show how this could be done.
MyClient.someMethodOneWay() is the wrapper method for MyService.someMethod().
Here's the new code in MyClientImpl.java:

@Service(MyClient.class)
@Scope(COMPOSITE)
public class MyClientImpl implements MyClient, MyServiceCallback {

private MyService myService;
static String result;
private MyClient myClient;
private RequestContext context;

@Context
protected void setContext(RequestContext context) {
this.context = context;
myClient = (MyClient)context.getServiceReference().getService();
}

@Reference
public void setMyService(MyService myService) {
this.myService = myService;
}

public void someMethodOneWay(String arg) {
myService.someMethod(arg);
}

public void aClientMethod() {
System.out.println(aClientMethod on thread  + Thread.currentThread());
myClient.someMethodOneWay( - someMethod );
System.out.println(aClientMethod return from someMethod on thread  + 
Thread.currentThread());
}

public void receiveResult(String result) {
System.out.println(receiveResult on thread  + Thread.currentThread());
System.out.println(Result:  + result);
MyClientImpl.result = result;
}
}

and in MyClient.java:

public interface MyClient {
void aClientMethod();

@OneWay
void someMethodOneWay(String arg);
}

and in MyService.java:

@Remotable
@Callback(MyServiceCallback.class)
public interface MyService {

String someMethod(String arg);
}

  Simon

Nishant Joshi wrote:


Hi, I am also trying to execute callback service with latest Tuscany code
and have modified simple-callback example with Tuscany sample. I m using
@Callback and @OneWay together, @OneWay is use with void type only than what
is with other return type values method ?
I have just tried to put @OneWay with String getAddress(String name)
method but it was returning me null value.
I have mainly one question,

If my callback service is returning a value(say String) and i want to work
it like @OneWay, what should i do?






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

Re: SCA WCF Integration

[Simon Nash]

You are correct that in Tuscany currently we don't have any way to
make a WCF Web service part of the SCA domain.

I think there are (at least) two options for how you could do this.

1. Use binding.ws on a SCDL reference to connect from the SCA domain
   to the WCF Web service.  The reference is part of the SCA domain but
   the WCF Web service that it invokes is not part of the SCA domain.

2. Create an SCA service that encapsulates the WCF service, and wire
   to this SCA service in the usual way.  The encapsulating SCA service
   is part of the SCA domain.  It would be possible to create a new
   component implementation type implementation.wcf to specify this
   encapsulation and perform the necessary WCF invocations.

This is a great topic to discuss and I'm sure others will have other
alternatives and opinions on the pros and cons of various approaches.

  Simon

James, Steven wrote:


I have a question regarding WCF and SCA integration which I am hoping
someone in this list can give clarity to.

As far as I see it currently a WCF Web service is not part of the
SCADomain. If a composed component had a dependency on a WCF component
could an explicit reference be set to that WCF web service in the SCDL
file? Or is this an internal matter and how we connect and invoke the
WCF component should be encapsulated in our SCA component? 


Regards,

Steve




This e-mail and any attachment is for authorised use by the intended 
recipient(s) only. It may contain proprietary material, confidential 
information and/or be subject to legal privilege. It should not be copied, 
disclosed to, retained or used by, any other party. If you are not an intended 
recipient then please promptly delete this e-mail and any attachment and all 
copies and inform the sender. Thank you.

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

Fixing TUSCANY-1849 in the 1.0.1 release

[Simon Nash]

Since it appears we are going to have a 1.0.1 release, I'd like
to propose fixing TUSCANY-1849 in this release.  This would make
1.0.1 non-interoperable with 1.0, but 1.0.1 would be interoperable
with 1.1 and future releases.  The alternative is to defer this
fix until 1.1, which would make 1.0.1 interoperable with 1.0, but
1.0.1 would be non-interoperable with 1.1 and future releases.

For Tuscany users who have a distributed environment with multiple
Tuscany nodes, making this change in 1.0.1 would mean that all
Tuscany 1.0 nodes need to be upgraded to 1.0.1 at the same time.

Does anyone object to putting this change into 1.0.1?

  Simon



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

Re: websphere web service deployment problem

[Simon Nash]

According to the SCDL schema, the implementation.* element must come
first in a service or reference.  This is what the
  element ref=sca:implementation minOccurs=0 maxOccurs=1 /
line in the schema is saying.

The message is telling you that the SCDL has elements appearing in a
different order.  (See TUSCANY-1738.)  The message is only a warning,
and the SCDL will be processed successfully.  To eliminate the message,
reorder the SCDL so that the implementation.java element comes first.

  Simon

Radim Kolarik wrote:


Hi Sebastien,

thanks for your help! It was the the custom Web container property as
described in the WebSphere fixpack.

I can also confirm now that it works with 6.1.0.11 fixpack as well, if
the property is set.

In the log file, however, we are getting something I am not sure we
were getting before:

[20/09/07 10:47:17:187 BST] 0036 ValidatingXML W   XMLSchema
validation problem in:
file:/c:/Program%20Files/IBM/WebSphere/AppServer/profiles/vws/installedApps/vws/example-sc-0_0_1_war.ear/example-sc-0.0.1.war/WEB-INF/classes/example-sc.composite,
line: 12, column: 7
cvc-complex-type.2.4.a: Invalid content was found starting with
element 'implementation.java'. One of
'{http://www.osoa.org/xmlns/sca/1.0:service,
http://www.osoa.org/xmlns/sca/1.0:reference,
http://www.osoa.org/xmlns/sca/1.0:property}' is expected.

Do you have an idea what could be wrong?

It looks to me that in http://www.osoa.org/xmlns/sca/1.0/sca-core.xsd
the following code suggests that only service, reference or property
elements are possible within the component:

- sequence
  element ref=sca:implementation minOccurs=0 maxOccurs=1 /
- choice minOccurs=0 maxOccurs=unbounded
  element name=service type=sca:ComponentService /
  element name=reference type=sca:ComponentReference /
  element name=property type=sca:Property /
  /choice
  any namespace=##other processContents=lax minOccurs=0
maxOccurs=unbounded /
  /sequence

We also have implementation.java there and it seems to be a valid
option based on several examples, including examples in the spec.

Thanks,
Radim


On 9/19/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:


Radim Kolarik wrote:


Hi Simon,

unfortunatelly I am seeing the same problem on WAS 6.1.0.9.

Sebastien, do you still have the WAS environment? Could you try to
deploy RC3 based example web service on it?

Thanks a lot,
Radim




It works for me.

I need more precise information to be able to help.

- which web service based sample? helloworld? calculator? built
yourself? using mvn or ant?
- the steps you are following to install and run the sample and the
exact output you are getting when you run it
- whether or not you have configured the WAR classloader parent last
and single classloader
- whether or not you have configured the custom Web container property
as described in the WebSphere fixpack at [1]
- the time of the error
- your SystemOut.log and SystemError.log files
- the FFDC files created in yout logs directory at the time of the error

Could you please put that information in a JIRA. I'm watching the JIRA
notifications so I'll get notified when you do so, and will investigate
quickly. Thanks.

[1] http://www-1.ibm.com/support/docview.wss?uid=swg24014758

Thanks.

--
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: websphere web service deployment problem

[Simon Nash]

See inline.

  Simon

Radim Kolarik wrote:


Oh, sorry about the stack trace, it only occurs with older version of
Tuscany when TuscanyServlet is used instead of filters.

I am now using Tuscany snapshot from the Maven repository dated 4th
September, with filters set up in web.xml, but still no luck on
Websphere. There is now no warning or exception in the log, but the
service is not being picked up. It is being picked up in Tomcat.

Do you have any ideas?

Thanks,
Radim

On 9/13/07, Radim Kolarik [EMAIL PROTECTED] wrote:


Hi Yang,

thank you for your suggestions.

I am sure I use the correct root context, because I can access a JSP
within the application successfully. It seems to me that the axis
service is not being recognized at
http://localhost:9201/contextRoot/componentName/serviceName.


I think this might be connected with the port number.  If your
.composite file just uses the binding.ws/ element with dynamic WSDL
generation and no uri attribute, then Tuscany will construct a default
URI.  There's a hardcoded port number of 8085 in the Axis2ServiceProvider
code, but I think in a webapp environment Tuscany would look for the
webapp server's configured port or fall back to 8080 if it doesn't know
what this is.  (I'm not 100% sure of the details of how this works.)

In the WebSphere environment you are using a port number of 9201 but
Tuscany doesn't know about this port number.  Maybe there's an API we
could use to get it from WebSphere, or some configuration that could be
set to override the default 8080.  There was discussion on the list
(see [1]) about adding the ability to set a system property for the
default port number.  This would require the WebSphere startup
configuration to include this system property.  This would be better
than having the port number in the .composite file, as it would allow
the same war to be deployed on different servers that use different
port numbers.

To confirm that this is the problem, can you try adding an explicit
uri attribute to the binding.ws/ element?  (If you are using explicit
WSDL and specifying a port in binding.ws, then you would need do this
in your WSDL port definition instead.)  The value of the uri attribute
is the full URI for the service, so in your case it is:
 binding.ws uri=http://localhost:9201/contextRoot/componentName/serviceName;

If this works, then we know the port number is the problem.  The longer
term solution will be to provide a suitable way of configuring the port
so it's not hard wired into the .composite file.

  Simon

[1] http://www.mail-archive.com/[EMAIL PROTECTED]/msg22977.html


It is very strange, because if I deploy the same WAR to Tomcat, it works fine.

We have also tried attaching a static WSDL file, again, that gets
displayed fine in Tomcat, but on Websphere, we get:

[9/13/07 12:36:14:309 IST] 0035 WebAppE   [Servlet
Error]-[TuscanyServlet]: java.lang.StringIndexOutOfBoundsException
  at java.lang.String.substring(String.java:1081)
  at 
org.apache.tuscany.sca.binding.ws.axis2.TuscanyListingAgent.setContextRoot(TuscanyListingAgent.java:286)
  at 
org.apache.tuscany.sca.binding.ws.axis2.TuscanyListingAgent.processListService(TuscanyListingAgent.java:102)
  at 
org.apache.tuscany.sca.binding.ws.axis2.Axis2ServiceServlet.doGet(Axis2ServiceServlet.java:260)
  at javax.servlet.http.HttpServlet.service(HttpServlet.java:743)
  at 
org.apache.tuscany.sca.binding.ws.axis2.Axis2ServiceServlet.service(Axis2ServiceServlet.java:235)
  at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
  at 
org.apache.tuscany.sca.host.webapp.WebAppRequestDispatcher.forward(WebAppRequestDispatcher.java:77)
  at 
org.apache.tuscany.sca.host.webapp.TuscanyServlet.service(TuscanyServlet.java:63)
  at 
com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:966)
  at 
com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:478)
  at 
com.ibm.ws.wswebcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:463)
  at 
com.ibm.ws.webcontainer.servlet.CacheServletWrapper.handleRequest(CacheServletWrapper.java:92)
  at 
com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:744)
  at 
com.ibm.ws.wswebcontainer.WebContainer.handleRequest(WebContainer.java:1425)
  at 
com.ibm.ws.webcontainer.channel.WCChannelLink.ready(WCChannelLink.java:92)
  at 
com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleDiscrimination(HttpInboundLink.java:465)
  at 
com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleNewInformation(HttpInboundLink.java:394)
  at 
com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.ready(HttpInboundLink.java:274)
  at 
com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.sendToDiscriminators(NewConnectionInitialReadCallback.java:214)
  at 
com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.complete(NewConnectionInitialReadCallback.java:113)

Re: context annotation

[Simon Nash]

This annotation is described here:
 
http://osoa.org/download/attachments/35/SCA_JavaAnnotationsAndAPIs_V100.pdf?version=1

It is used to mark a ComponentContext or RequestContext field or setter
method so that the runtime can inject the corresponding object.

  Simon

mayank sharma wrote:


hi People,

I am newbie looking for some help on @context annotation.Can one of you
please explain me or provide me pointers where I can get more information on
this annotation. Describing with a small example would be gr8.

Thanks in advance.
Waiting for a quick reply.
Mayank Sharma





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

Re: Contents of Tuscany SCA 1.0 release, was: SCA 0.92 release?

[Simon Nash]

Hi Radim,
It's great to get your feedback on this.  Your posts to the user list
(including those with tough questions, like Java2WSDL and on the fly
WSDL generation :-) have been much appreciated.

I am currently working on asynchronous support for callbacks.
The @OneWay part of async is already working in the current trunk and
we just need a test case for it, which I will add when I have got
callbacks into reasonable shape.  At the moment I am working on
TUSCANY-1496 which will greatly simplify the callback implementation
by treating callbacks almost identically to forward calls both within
the core framework and within binding extensions.  I am also looking
at TUSCANY-1347 and TUSCANY-1500 which relate to slightly more advanced
use cases for callbacks including some gaps in our support for the
full Java API for callbacks.

Callbacks and conversations are intimately connected and SimonL and I
have had one discussion about this and some of the spec points that are
not 100% clear.  I'm expecting to work with SimonL to bring together
his work on conversations with my work on callbacks, and to have full
support in the 1.0 release for both callbacks and conversations (and
the interactions between them).  This support would include the core
framework as well as the Web Service binding.

After this is all taken care of, I would be very interested in putting
together a sample of the type that you describe with complex POJO types
(which I would like to represent as SDOs) and Web Services.  This would
require getting the SDO tooling story sorted as well.  Of course,
someone else might get to this one ahead of me :-)  I would be interested
to know whether this would meet your requirement, or whether you are
specifically looking to pass around non-SDO POJOs.

  Simon

Radim Kolarik wrote:


Hi Ant,

the top priority regarding web services would be having on fly
generation of WSDL, without the need of having to supply own file.
Axis2 can do it for its services described in services.xml file. It
would also help if there was a working example that would use complex
POJO types as parameters and results of a service call, deployed as a
web service, as I am struggling to make this work. It is not clear to
me if I need to supply services.xml or not for Axis to make complex
types working (register serializers/deserializers).

Also important are following items in your list, however, not as
important as the above issues. The items are ordered by priority.

- WS Security
- Sort out our WSDL tooling story - get SDO integrated into Axis2?
- asynchronous services
- conversational services

Thanks a lot!
Radim

On 8/7/07, ant elder [EMAIL PROTECTED] wrote:


http://cwiki.apache.org/confluence/display/TUSCANYWIKI/SCA+Java+Next+Release+Contentshttp://cwiki.apache.org/confluence/display/TUSCANYWIKI/SCA+Java+Next+Release+Contents

Note that its likely we wont have time to get everything listed there done
in 1.0 so please say which things are important to you to help us prioritize
what does get done.

 ...ant

On 8/7/07, Radim Kolarik  [EMAIL PROTECTED] wrote:


Hi Jean-Sebastien,

where is the SCA Java Releases wiki page which lists some work
items in ws binding space, that you mentioned?

Thanks,
Radim

On 8/6/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:


[snip]


Bringing this thread up again as time is ticking on if we want to get


a


release out this month. How would people feel about taking a branch


for this


release in a bit less than 2 weeks, say aiming for the 14/15th of


August?


That should just about give enough time for clean up and voting to


get a


release out by the end of  August.

Another thing I wondered about was the name, we've been talking about


this


being 0.92, how about something higher to show we're getting closer,


maybe


0.95 or 0.98 or even 0.99? (that prompts a what/when is 1.0, I'll


start a


separate thread about that)

  ...ant



What/when is 1.0? Good question :) There has been a lot of progress in
the recent 0.90 and 0.91 releases and I agree that Tuscany SCA is
getting close to a 1.0 release.

So, let's start discussing What is Tuscany 1.0. I'm moving this thread
to the tuscany-user list as I'd like to get feedback, requests and ideas
from Tuscany users.

Speaking for myself, here's some thoughts on what I'm interested in
having in a 1.0 release:

* SCA assembly spec 1.0 support
Looks close to complete here, I think it just needs a little more
testing and a simple implementation of a distributed domain. Simon seems



to be making good progress in that area. Also I'd like to have a simple
admin console to add/remove contributions and composites and allocate
components to nodes.

* SCA Policy framework 1.0
Modules policy and policy-xml are taking shape. Having one concrete
policy like Security implemented on top the framework would be good.
Maybe Venkat could give his thoughts on this?

* Extension points for component implementations, bindings, databindings
and policies

Re: Services and WSDL files

[Simon Nash]

Hi Radim,
I'm glad to see you solved your Jetty/Tomcat problem.  See inline
responses below to your questions on WSDL generation.

  Simon

Radim Kolarik wrote:


Hi,

thanks for all your support, removing tuscany-host-jetty jar from the
classpath solved the problem! I can now run the service from Tomcat.

I would just like to clarify with you few more things that were
mentioned in this thread. Ant mentioned, that he would start working
on something for next release of Tuscany, which is due to be released
in August. Did you mean also the on the fly generation of WSDL, to
support services without pre existing WSDL file?


I don't know the details of how this will be supported.  I'd expect
that it would include on the fly generation, as the client would need
to get WSDL from somewhere.  Perhaps someone else can add more detail.


How can I generate WSDL file for SCA service using Tuscany at the
moment? And does the generation support SDOs as parameters / results
of services?


I'm not an expert in this area, so if anyone knows more about the
current state of things please jump in and correct me.  There is some
code in java2wsdl to handle SDO types but it is not in active use
and it may well have problems.  It would be good to get this working,
and any help would be appreciated :-)

As a start, could you say a bit more about what you would like to do?
Have you got some Java SDO types that were generated from XSD schemas?
If so, then the goal should be to generate WSDL that picks up your
existing schemas.  There is some code in java2wsdl to do this but
I don't know how well it's working.  Have you tried to use this and
come across a problem?


Thanks,
Radim



 On 7/26/07, Simon Laws [EMAIL PROTECTED] wrote:
 (cut)



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

Re: Running standalone samples in Eclipse

[Simon Nash]

Thanks Luciano.  It would be good to get this information into the
SCA Java page of the Web site when we are all OK with it.  I'll give
it a try.

  Simon

Luciano Resende wrote:


Thanks Francesco, I'll update the SCA wiki with this detailed steps :

http://wiki.apache.org/ws/Tuscany/TuscanyJava/SCA_Java





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

[Announce] Apache Incubator Tuscany SCA Java 1.0-incubator-M2 release

[Simon Nash]

The Apache Incubator Tuscany team is pleased to announce the availability
of the SCA Java 1.0-incubator-M2 release, together with a restructured
Web site with enhanced content and better organization.  Information about
Tuscany, including details of the release contents and download links can
be found at:
  http://incubator.apache.org/tuscany

The aim of the Apache Tuscany project is to create, as a community, a robust
infrastructure that simplifies the development of SOA-based systems.  This
M2 release contains a number of enhancements over the previous M1 release.
The major features are as follows:

* SCA specification compliance. Assembly (V0.96), Java Client and 
Implementation (V0.95):
Recursive composite model (implementation.composite and include)
Support for component properties (simple types only)
Asynchronous oneway and request with callback
Java interface and WSDL 1.1 portType
* Improved core for flexibility and extensibility
Refactored to provide the default implementation of the SPI contracts
Packaging/deployment
Scope management
IoC
Autowire
Improved classloader isolation
Maven-based artifact repository
A Data Binding Framework
* Improved Extension model and SPI
* Tuscany Standalone runtime launcher
* Tomcat integration to host Tuscany web applications
* Tuscany War Plugin to build web applications
* New and improved bindings:
Axis2, upgraded to version 1.1
RMI
* Component Implementation:
JavaScript
Ruby
Spring
* Data Bindings:
AXIOM
SDO
* Additional samples
RMI Service and RMI Reference from a standalone Tuscany runtime
A combo sample (Calculator-Combo) that demonstrates
  - assembly of different technologies using component implementations in 
Java, JavaScript, and Ruby
  - binding of service references to Web service and RMI Service endpoints
  - a simple demonstration of property configuration and composite 
component implementation
Asynchronous invocation

This release is available for download from
  http://incubator.apache.org/tuscany/sca_downloads.html

If you have questions, feedback, or would like to get involved in the
Tuscany project, please join the mailing lists (tuscany-dev@ws.apache.org
or tuscany-user@ws.apache.org) and let us know your thoughts.

The Apache Incubator Tuscany Team


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