I was wondering.. how come this zip:
.../distribution/target/apache-tuscany-sca-1.3-SNAPSHOT.zip
gets things like the wsdl4j jar built into its .../lib directory when I
build it from the branches/sca-java-1.3 directory but not from the trunk?
The binary download available at the website has the
This seems like an interesting issue and I was curious about a couple
things:
First, I'm wondering why I didn't recreate the error that others noticed.
Any ideas?
Next, I was wondering what implications there are here. I'm not 100% sure
but I'm guessing in the bottom-up case, without the Java w
may
have failed to build?? But I"m not doing anything different
Thanks, Scott
On Wed, Jun 25, 2008 at 9:38 AM, Simon Laws <[EMAIL PROTECTED]>
wrote:
> On Wed, Jun 25, 2008 at 2:33 PM, Scott Kurz <[EMAIL PROTECTED]> wrote:
>
> > I was wondering.. how come this
ed, Jun 25, 2008 at 11:31 AM, Luciano Resende <[EMAIL PROTECTED]>
wrote:
> Simon, have you been merging these distribution changes to trunk ?
>
> On Wed, Jun 25, 2008 at 7:29 AM, Simon Laws <[EMAIL PROTECTED]>
> wrote:
> > On Wed, Jun 25, 2008 at 3:13 PM, Scott Kurz &
I'm noticing a difference in the JAXB->Axiom serialization produced by the
new databinding-jaxb-axiom transform compared to the old transform
(JAXB2Node, Node2XMLStreamReader,XMLStreamReader2OMElement).
The difference is caused by the fact that the older transform (before
databinding-jaxb-axiom) h
nto the JAXB metadata. The
> JAXB2OMElement uses the OMDataSource to lazily serialize JAXB data into XML
> stream. It would be difficult to adjust the element name at the stream level
> especially considering the performance penalty. Do you have any good ideas?
>
> Thanks,
> Raymo
I'm building the HEAD at r678446.
I'm using IBM JRE:
java version "1.5.0"
Java(TM) 2 Runtime Environment, Standard Edition (build pxi32devifx-20070608
(SR5+IY99712))
IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Linux x86-32 j9vmxi3223-20070426
(JIT enabled)
J9VM - 20070420_12448_lHdSMR
JIT - 2007
(Copied this from the note about my other build problem. I wonder if I
should try completely deleting my maven repo???
I'm building the HEAD at r678446.
I'm using IBM JRE:
java version "1.5.0"
Java(TM) 2 Runtime Environment, Standard Edition (build pxi32devifx-20070608
(SR5+IY99712))
IBM J9 VM
In experimenting with using the Mediator from a binding impl, rather than
only via the DataTransformationInterceptor on the wire, I found myself
needing to use the exact same logic (that the DataTransformationInterceptor
uses) to map an Message's fault body to both the source/target fault
DataType.
; transformation logic for the payload (input/output/fault) out
> of DataTransformationInterceptor to become OperationDataTransformer (or a
> better name) and expose it as a utility service? This way, binding or
> implementation providers can use it to transform input, output and fault
>
re a new reference,
using the interface Class passed into getService(), so I'm not sure what
piece of the puzzle isn't quite there today.
Thanks,
Scott
On Tue, Jul 29, 2008 at 10:49 AM, Simon Laws <[EMAIL PROTECTED]>wrote:
>
>
> On Sat, Jul 26, 2008 at 2:57 PM,
didn't look totally useless.
Scott
On Wed, Jul 30, 2008 at 1:43 PM, Simon Laws <[EMAIL PROTECTED]>wrote:
>
>
> On Tue, Jul 29, 2008 at 4:41 PM, Simon Laws <[EMAIL PROTECTED]>wrote:
>
>>
>>
>> On Tue, Jul 29, 2008 at 4:25 PM, Scott Kurz <[EMAIL PR
On Thu, Jul 31, 2008 at 10:18 AM, Simon Laws <[EMAIL PROTECTED]>wrote:
>
>
> On Thu, Jul 31, 2008 at 3:04 PM, Scott Kurz (JIRA) > wrote:
>
>>
>>[
>> https://issues.apache.org/jira/browse/TUSCANY-2519?page=com.atlassian.jira.plugin.system.issuetabpanels
I'm stuck on this build break (in HEAD). Skimmed through the discussions,
seemed like one suggestion was to revert
Sebastien's fix in r679944... but that just let me with a different set of
errors.
Anyone know how to get past it?
Thanks,
Scott
On Fri, Jul 25, 2008 at 9:35 PM, Jean-Sebastien De
PM, Simon Laws <[EMAIL PROTECTED]>wrote:
>
>
> On Fri, Aug 1, 2008 at 5:16 PM, Scott Kurz <[EMAIL PROTECTED]> wrote:
>
>> I'm stuck on this build break (in HEAD). Skimmed through the discussions,
>> seemed like one suggestion was to revert
>> Seba
Raymond,
So in the fix for TUSCANY-2389, as Raymond's comment along with his fix to
BaseBeanGenerator indicates:
"Set the nillable consistent with what wsgen produces.."
we use a different bottom-up mapping for arrays on parm/ret types than than
we do for collections.
Specifically, in the ge
.class.isAssignableFrom(javaClass) || javaClass.isArray();
> // TUSCANY-2389: Set the nillable consistent with what wsgen
> produces
> this.nillable = javaClass.isArray();
>
> Thanks,
> Raymond
>
> From: Scott Kurz
> Sent: Monday, August 18, 2008 11:18 AM
Does anyone know what this problem could be?
testRegisterServletMappingSSL(org.apache.tuscany.sca.http.jetty.JettyServerTestCase)
Time elapsed: 1.407 sec <<< ERROR!
java.net.SocketException: Cannot find the specified class
java.security.PrivilegedActionException: java.lang.ClassNotFoundException:
Simon,
Yes I am using a JDK from WebSphere. You mentioned you have a similar
JDK... is yours from WebSphere as well?
Thanks,
Scott
[EMAIL PROTECTED]>wrote:
>
>
> On Mon, Sep 8, 2008 at 7:26 PM, Scott Kurz <[EMAIL PROTECTED]> wrote:
>
>> Simon,
>>
>> Yes I am using a JDK from WebSphere. You mentioned you have a similar
>> JDK... is yours from WebSphere as well?
>>
>> Than
yImpl
ssl.ServerSocketFactory.provider=com.ibm.jsse2.SSLServerSocketFactoryImpl
Thanks,
Scott
On Tue, Sep 9, 2008 at 10:21 AM, Scott Kurz <[EMAIL PROTECTED]> wrote:
> OK so at one level the problem is that in using the WAS JDK I've got in
> my file:
> $JAVA_HOME/jre/lib/security/java.security
>
&g
Ah... that's another idea. Commenting them out completely and using
defaults worked for me too.
Thanks,
Scott
On Tue, Sep 9, 2008 at 10:33 AM, Simon Laws <[EMAIL PROTECTED]>wrote:
>
>
> On Tue, Sep 9, 2008 at 3:21 PM, Scott Kurz <[EMAIL PROTECTED]> wrote:
>
Dave,
The issue is that we look at the interface to determine what types to
register with the JAXBContext. Your interface only shows java.lang.Object
as the input type... and though
com.example.jms.JMSPOJO extends Object, the JAXBContext was not set up to
know about this type.
I was wondering
Does anyone know what I've got set up wrong?
INFO: Starting node: standard-types-service.composite
Sep 10, 2008 11:16:37 AM org.apache.tuscany.sca.http.jetty.JettyServer
addServletMapping
INFO: Added Servlet mapping: ..
*X connection to localhost:10.0 broken (explicit kill or server shutdown).
Wed, Sep 10, 2008 at 4:27 PM, Scott Kurz <[EMAIL PROTECTED]> wrote:
>
>> Does anyone know what I've got set up wrong?
>>
>> INFO: Starting node: standard-types-service.composite
>> Sep 10, 2008 11:16:37 AM org.apache.tuscany.sca.http.jetty.JettyServer
>>
> properties in the subtype lost.
>
> Thanks,
> Raymond
>
> From: Scott Kurz
> Sent: Wednesday, September 10, 2008 6:53 AM
> To: dev@tuscany.apache.org
> Subject: Re: JAXBException
>
>
>
> Dave,
>
> The issue is that we look at the interface to determine
people create JAXBContext in this case? What if USAddress and
> UKAddress are from different packages?
>
> BTW, I'm not sure how we can scan the java classes on the classpath. Maybe
> it works for URLClassLoader but not for all cases.
>
> Thanks,
> Raymond
>
> F
Simon,
No I didn't open a JIRA for this. If this is bad practice I apologize. I
thought adding a couple lines just to a vtest test would be something no one
would care about, so maybe I erred on the side of not saying anything.
Scott
On Thu, Sep 18, 2008 at 5:11 AM, Simon Laws <[EMAIL PROTECT
I was wondering if there were any reason why trying to introduce pooling of
stateless-scoped instances would be non-trivial.
(I don't believe we are doing this today; instead we create a new instance
each time.)
Otherwise I was planning to give it a try, after noticing specifically that
the refere
e
boundary, which doesn't actually buy us anything for stateless components
(unlike ejbCreate() for a SLSB, say), but the proxy injection is a bit
expensive.
Scott
On Mon, Oct 6, 2008 at 12:28 PM, Simon Laws <[EMAIL PROTECTED]>wrote:
>
>
> On Mon, Oct 6, 2008 at 4:56 PM
OK, So
On Fri, Oct 10, 2008 at 10:08 AM, Simon Laws <[EMAIL PROTECTED]>wrote:
>
> Hi Scott
>
> Can you say a little more about what the implications for pooling stateless
> instances would be, for example,
>
> 1st call - Create object
>@Reference injected
>@Init run
>
> 1st Operation exec
start the conversationand you have to
use programmatic means if you want this.
Scott
On Fri, Oct 10, 2008 at 12:18 PM, Simon Laws <[EMAIL PROTECTED]>wrote:
>
>
> On Fri, Oct 10, 2008 at 4:49 PM, Scott Kurz <[EMAIL PROTECTED]> wrote:
>
>> OK, So
>&g
I noticed, in file:
java/sca/modules/binding-ws-wsdlgen/src/main/java/org/apache/tuscany/sca/binding/ws/wsdlgen/Interface2WSDLGenerator.java
that we have the following code:
String action = ((JavaOperation)op).getAction();
if ((action == null || "".equals(action)) &&
!op.i
I added the code to make sure the Axis2 can figure out the operation for
> BARE style based on SOAP action.
>
> Thanks,
> Raymond
>
> From: Scott Kurz
> Sent: Monday, October 13, 2008 8:59 AM
> To: dev@tuscany.apache.org
> Subject: runtime Java2WSDL and soapAction
>
&g
it down. All I can say to this
> question is that the above is the spec intention, and is a principle that
> will cause the least surprise and most success for users.
>
>
> Dave
>
> - Original Message -
> *From:* Scott Kurz <[EMAIL PROTECTED]>
> *To:* dev@t
I noticed an annoyance in the scenario that we are developing in a top-down
style, starting with two WSDL interfaces, which we wish to use as a
forward/callback pair.
Since this is top-down, we generate Java interfaces from each WSDL using
something like wsimport. The annoyance is that I have to
28, 2008 at 2:35 PM, Scott Kurz <[EMAIL PROTECTED]> wrote:
>
>> I noticed an annoyance in the scenario that we are developing in a
>> top-down style, starting with two WSDL interfaces, which we wish to use as a
>> forward/callback pair.
>>
>> Since this is
irectional interface then should be able
to deal with an unannotated-forward interface in an introspected
componentType.
Or is there some API where this is really critical that I'm missing...?
On Wed, Oct 29, 2008 at 9:35 AM, Scott Kurz <[EMAIL PROTECTED]> wrote:
> Hi Simon,
>
>
e I'm asking about but more generally the case in which the
component definition explicitly connects the forward/callback interfaces on
the component reference definition.
On Wed, Oct 29, 2008 at 10:07 AM, Simon Laws <[EMAIL PROTECTED]>wrote:
>
>
> On Wed, Oct 29, 2008 at 1:
Just a follow-up to a discussion we had a few months ago on how to use
derived/subclass JAXB types together with interfaces defined
in terms of base/superclass types..
In the JAXB 2.1 level of tooling, wsimport leverages a new JAXB annotation
@XmlSeeAlso to make this a lot smoother.
So if you
o hint sub types :-).
>
> Thanks,
> Raymond
>
> From: Scott Kurz
> Sent: Thursday, November 20, 2008 11:29 AM
> To: dev@tuscany.apache.org
> Subject: JAXB and derived types / subclasses - better story in Java 6 /
> JAXB 2.1
>
>
>
> Just a follow-up to a discu
You have the right idea but I think your SCDL syntax is a bit off.
Instead of:
Ku
Jun
Guo
you could write:
http://www.osoa.org/xmlns/sca/1.0";
xmlns:xsd="http://www.w3.org/2001/XMLSchema";
xmlns:cust="http://ww
Simon,
I was able to recreate this outside of Tuscany using a Java 6 JRE with a
call to JAXBContext.generateSchemas().
(I only borrowed from Tuscany the JAXBTypeHelper$DOMResolver which I don't
think matters... but the exact way the SchemaOutputResolver is used seems a
bit odd).
Anyway my wrappe
This might seem nit-picky... but where do are the possible values for the
@type attribute of BindingProperty defined?
I see in the OASIS JMS Binding spec simply this schema def:
776
777
778
779
780
782
783
784
and our JMSBindingProcessor recognizes the types via code:
private void p
Douglas,
Since our impl uses JAXB by default to map from the XML
wireformat to the application Java, the JAXB runtime needs to be able to
deserialize into your input/output types. If the types don't contain JAXB
annotations, they need to follow the pattern that JAXB expects, i.e. they
must cont
Or did I miss some ability of the XML APIs
we're already using?
Thanks,
Scott
On Wed, Feb 4, 2009 at 8:17 AM, Simon Laws wrote:
>
>
> On Tue, Feb 3, 2009 at 5:20 PM, Scott Kurz wrote:
>
>> This might seem nit-picky... but where do are the possible values f
Not sure if I'm completely understanding the situation, but would another
way of describing this problem be to say that the callback (into
HelloworldXComponent) is resolved too aggressively in the binding.sca
implementation?
If the forward call were coming into a composite-scoped component
(Hellow
Sorry,
I meant the callback "out from" HelloworldXComponent ... not "in to"
HelloworldXComponent
On Wed, Feb 4, 2009 at 4:08 PM, Scott Kurz wrote:
> Not sure if I'm completely understanding the situation, but would another
> way of describing this problem be
Raymond,
I don't see how that spec discussion relates to this conversation (though I
couldn't follow the OASIS links from that link).
That conversation suggests that COMPOSITE scope should be subdivided into
DOMAIN scope (a true singleton across the entire domain) and PROCESS scope
(a singleton p
I thought it was useful to point out that was specifically a problem w/ a
callback over binding.sca, as the proxy set up for a binding.ws (axis2)
callback should be able to call back to the right client today, right?
Scott
On Fri, Feb 6, 2009 at 12:55 PM, Raymond Feng wrote:
> Yes, the injecte
Simon,
On Tue, Feb 10, 2009 at 4:03 AM, Simon Nash wrote:
> Scott Kurz wrote:
>
>> I thought it was useful to point out that was specifically a problem w/ a
>> callback over binding.sca, as the proxy set up for a binding.ws <
>> http://binding.ws> (axis2) callba
Simon,
Just trying to educate myself here...
On Tue, Feb 10, 2009 at 10:27 AM, Simon Nash wrote:
>
> For binding-ws-axis2, the callback endpoint from the input message
> is resolved at the time the proxy is created, not at the time the
> proxy is called. This approach is used for all binding t
Simon,
Right, though I just wanted to clarify my proposal involved treating checked
and unchecked exceptions differently.
I like the idea of handling the checked exception with a wireFormat-specific
means (e.g. for object WF just serialize the exc into
an ObjectMessage and for dflt text/xml only
I'd been thinking it might be more useful to use the message of the
innermost chained exception (which would more represent the "first failure")
than the outermost... but I didn't want to get too bogged down in that
detail... so I wrote leaving that up in the air.
Agreed that if we provide some us
So in the absence of a spec, the conventions we use in the various
wireFormats are like working specs. I just wanted to capture this in some
sort of documentation.
For example, for wireFormat.jmsObject we've decided in the code to:
* map input parameters to an Object[]
* map outputs to a single
I feel like I remember seeing this conversation before but can't find it in
my mail search.
Just noticing that if we throw a RuntimeException from an @Init method in a
composite-scoped component ... then the instance gets used anyway even
though it may have failed to initialize.
Was thinking it w
be tweaked before it is included in
> the specification.
>
>
>
> Thanks,
>
>
>
> Mark
> --
>
> *From:* Scott Kurz [mailto:scottk...@gmail.com]
> *Sent:* 16 February 2009 23:54
> *To:* dev@tuscany.apache.org
> *Subject:* What t
On Tue, Mar 10, 2009 at 12:26 PM, Raymond Feng wrote:
>
> * Having an example will help us better understand the requirements.
> * For each operation, there is an inputType and an outputType. They can be
> configured with different databindings. It's up to the binding provider to
> understand the
On Mon, Mar 16, 2009 at 11:09 AM, Simon Laws wrote:
>
> Currently the infrastructure relies on resetting the databinding on
> the interface for a service or reference and the wire format providers
> take charge of doing this. However the function is such at the moment
> that it resets the data bin
On Wed, Mar 18, 2009 at 7:34 PM, Luciano Resende wrote:
> I think the issue is, when wsdlLocation and schemaLocation is
> provided, but it fails to properly resolve... should we fall back to
> the SCA resolution mechanism or should we fail.
We do have to deal with this issue.
However, I think w
On Thu, Mar 19, 2009 at 1:57 PM, ant elder wrote:
> I think ByteMessage is preferred by some messaging folks as it avoids
> some of the encoding issues that can arise when using TextMessage
> across platforms, so maybe bytes should be the default?
>
> ...ant
I noticed that the W3 SOAP/JMS worki
On Fri, Mar 20, 2009 at 10:11 AM, Simon Laws wrote:
> A single static default wire format is simpler to code/describe. I
> don't think it's as user friendly but I could live with it.
So with your approach, Simon, the pattern we're setting up is
something like: "if I have a decision to make wrt
+1 and thank you for summarizing Simon.
Scott
On Tue, Mar 24, 2009 at 7:34 AM, Simon Laws wrote:
> So, base on comments from Scott and Raymond, these are the changes I'm
> planning
>
> - Fix up the binding.jms XSD to allow "any" content within the
> . This will allow wireFormat elements from the Tuscany
> namespace to be included here whic
I was looking at adding an operationSelector to use any user-specified
"user property" (not just 'scaOperationName') to hold the operation
name.
It seems the one oS we currently have,
OperationSelectorJMSDefaultServiceInterceptor, has some callback
destination stuff in it which should ideally be f
Simon,
Thanks for responding.. replies below...
On Wed, Mar 25, 2009 at 11:09 AM, Simon Laws wrote:
> This logic seems to be setting callback destination information into
> the forward message. So that the invoker code can handle callbacks
> properly. The URI from this callback reference will b
Simon, that all sounds good to me.
It was only recently that I'd even run across the need to maybe look
at isWrapperStyle(), from say, a binding impl, in the case of
implementing the wireFormat.jmsdefault behavior of sending a single
argument unwrapped. The new API should work well with that use
Simon,
Still looking over your changes just wanted to respond that my
impression & working understanding has been that we assume we have
unique operation names in a bunch of places and use String.equals()
for operation name matching... certainly within some binding
implementations... so making
Just wanted to note that it seems that an additional burden on the
runtime implementor to support this API is to recognize if the service
is described by .
If so the runtime has to establish this WSDL interface on the runtime
representation of the reference built for the proxy without having the
d
On Wed, Apr 22, 2009 at 10:10 AM, ant elder wrote:
> would not be invokeable via SCAClient as the service isn't exposed with the
> SCA binding.
I'd also assume the service would need to be exposed over binding.sca.
Continuing my line of thought... if there is any variability in
wireFormat f
On Wed, Apr 22, 2009 at 11:54 AM, Raymond Feng wrote:
> Here are my two cents based on my understanding of the OASIS spec:
>
> 1) SCAClient.getService() is similar to connect an SCA service using a dummy
> reference without any binding declarations. The OASIS spec says the binding
> for the refere
Ram,
Thanks for the updated summary.
I have a couple of questions, if you don't mind.
First, this is probably an obvious question, but by the "SCA
resolution mechanism" you mean:
1. first look in the current contribution
and if not found
2. then look for SCA contribution import/exports.
On Wed, Apr 22, 2009 at 3:55 PM, Raymond Feng wrote:
> 2892 If a reference does not have a binding, then the binding used can be
> any of the bindings
> 2893 specified by the service provider, as long as the intents attached to
> the reference and
> 2894 the service are all honoured.
That's inter
I was asking this question wrt, e.g. OMElement2JAXB.
If we have WS-I compliant WSDL then we always have a global element.
Is it because we're counting on this code to, say, deserialize
component property values expressed in SCDL documents?
Was planning on suggesting global elem unmarshalling as
Thanks. Replied...
On Thu, Apr 30, 2009 at 11:43 AM, Raymond Feng wrote:
> There are a few thoughts behind:
>
> 1) In SCA, JAXB objects are not always used for doc-lit wrapper style Web
> Service. There are cases that the transformer convert XML data into a JAXB
> object without a global element
On Thu, Apr 30, 2009 at 12:51 PM, Raymond Feng wrote:
> More comments inline.
> For example, we have a java method A talking to B:
>
> A:
> void updateAddress(String customerId, AddressSDO address)
>
> B:
> @RequestWrapper(...)
> @ResponseWrapper(...)
> void updateAddress(String customerId, A
Did we get this wrong again (my fault)?
In reading the OASIS spec again, I think we're supposed to:
1) take the service-side operationSelector's selected operationName,
2) look for a @selectedOperation (OASIS) / @nativeOperation (OSOA) in
an matching the result of 1)
3) determine the value of @n
Thanks for stating it so clearly Simon.
You're right. OSOA was not clear and one could read it either way,
and I'm only making my case regarding OSOA by looking at how OASIS has
clarified this.
I guess I'm just thinking given that @nativeOperation is an
unintuitive choice of attribute name to b
This is mainly a question for Raymond:
I was noticing in the databinding-jaxb-axiom module, we've dragged in
some potentially more optimized code doing the JAXB->AXIOM
serialization, e.g. the
org.apache.tuscany.sca.databinding.jaxb.axiom.ext.* classes
In class, JAXBDataSourceExt, I see this comm
I was just noticing that in the WireFormatJMSObjectServiceProvider ctor, we do:
// just point to the reference interface contract so no
// databinding transformation takes place
interfaceContract = service.getInterfaceContract();
So, with an componentType, this is fine as
Thanks Simon,
So we already support the mirror image case today where we need a WSDL
intf for the binding but have only a Java intf in the component; we
generate a WSDL if necessary.
So for the wf.jmsObject plus impl.bpel case, I suppose we could just
generate Java as well.
So each binding requ
Raymond,
Thanks but that didn't seem to work. I added a
part,ClassCachedJavaInterfaceFactoryImpl.java in r776802. If it's
complicated to explain maybe someone else could fix it up later if
needed... was just trying to do it the right way if possible.
Scott
How do you create a new Java file so it ends up looking like:
* @version $Rev: 656576 $ $Date: 2008-05-15 02:45:30 -0700 (Thu, 15 May 2008) $
when you extract/checkout from SVN?
Sorry if that's a dumb question..
Thanks, Scott
Say we wanted to invent an SCA annotation that injected an SDO
HelperContext into a Java impl field/method.(A change to the SCA
programming model would need to be discussed, but I wanted to try it
out on a prototype).
I was wondering what would be a nice way to do this?
Writing the class visi
Thanks for the detailed response Raymond.
I'm going to back over it but it sounds like you wouldn't have a basic
objection to introducing a implementation-java-runtime ->
databinding-sdo dependency?
Scott
OK, so you're saying to add my ObjectFactory corresponding to my visitor to
JavaImplementationProvider.handleResources()
we'd have to factor that into a new extension point NOW... rather than
later (whereas for simply registering the class visitor I could do
that programatically NOW and we could
Picking this thread up again, I wonder if a starting point might be to
define a new SPI that a binding could use to obtain a Java
InterfaceContract in the cases where we expect/require the
componentType IC to be Java.
E.g. in
org.apache.tuscany.sca.binding.jms.wireformat.jmsobject.runtime.WireFor
I'm not suggesting generating one from WSDL yet, until we understand
the use case(s) we'd need this in more detail.It might be nice to
throw an error if a Java interface is unavailable however.
Obviously we have a lot of bindings today and people have figured out
the trick... just seemed nicer
Picking this up again thanks Luciano and Raymond for the suggestions.
I found another approach. Though we may not have a full-blown
extension point we can actually use the ResourceObjectFactory and its
ResourceHost to accomplish this goal fairly easily.
I'd just need to add a ResourceHost fi
Simon,
Thanks for picking this up again.
>From the service-side perspective, this is a step towards enabling a
non-Tuscany client to consume our "unchecked exc" JMS Message. In my
mind the SOAP fault format was a bigger step towards this goal, but
how much bigger? Is SOAP fault more "standard
As a motivating use-case, how about:
1. Develop an impl.java component to the specialized REST interface
because I have in mind right from the start that I want to expose this
service over binding.atom.
2. Later, I want to invoke this component over some other binding
using an XML wire format usi
Luciano,
The case I mentioned was more of a bottom-up case , in that we started
with the Java REST-like interface.
So say I start with this interface, write a Java impl, expose a
service over . Now in order to invoke this same impl
over a different binding like , I generate an
and place this co
Do we really even want the path from the service-side binding.atom to
the service impl to include the DataTransformationInterceptor, given
that the binding makes its own invocation of the mediator?
What about using the usual trick of returning the componentType
interface in getBindingInterfaceCont
Luciano,
I think your code is pretty much equivalent to my suggestion of simply doing:
public InterfaceContract getBindingInterfaceContract() {
return service.getService().getInterfaceContract();
}
at least for the cases which we'd expect to work anyway.
In both cases, for a component impl wi
Was wondering if we missed something (or consciously decided not to
implement it?)
Do we agree that we're NOT setting the correlation ID per the
correlation scheme for a callback message (i.e setting the correlation
ID on the callback-direction request message based on the
forward-direction reques
Simon,
That was a helpful write up of the issues.
What about the idea of modifying the class file to specify an
@XmlType.name() equal to "" (rather than "##default"), so that we would
end up following this mapping rule per the JAXB spec.
otherwise if @XmlType.namespace() is
"##default" &&
Thanks Simon,
After considering some more, I'm going to take this up as a spec issue
(rather than argue for us to change our code)... as this sort of thing
I proposed would be conversational-like, and I don't think that's
where we want to go with this.
Scott
On Mon, Sep 28, 2009 at 9:14 AM, Simon Laws wrote:
> Quick update
>
> I spent some time looking at whether we could modify the data type on
> the fly at the point at where the Tuscany data types are generated.
> However it turns out that the WSDL generation needs to be driven from
> the wrappe
Hmm... so given you have tried that approach I'm going to play around
with the post processing approach. Part of me is thinking it might
not be so bad but then part of me is realizing that since I'm not
sure, I really don't fully know what I'm talking about ;)
Scott
Here is the OASIS discussion JIRA from my comment:
http://www.osoa.org/jira/browse/BINDINGS-97
1 - 100 of 306 matches
Mail list logo
