Vamsi,
It looks like all your failure cases require runtime Java2WSDL. In order
to generate a doc-lit-unwrapped WSDL from Java,
the Java should contain annotation:
@SOAPBinding(parameterStyle = SOAPBinding.ParameterStyle.BARE)
I believe this the new rewrite of the Java2WSDL code that Simon
From another angle, does any spec disallow us from viewing all public
setters on a Java impl as properties?
It does say an @Property denotes a property but seems to allow that the
converse isn't true.
So, while creating a rule that such a property with a setter but no
@Property must be listed in
Raymond,
Just curious: did you fix it in a way such that the .componentType property
definition matters or is the component property definition enough to have
the value injected?
On Thu, Jun 12, 2008 at 3:39 PM, Raymond Feng [EMAIL PROTECTED] wrote:
Hi,
It turned out this test case is not
/browse/TUSCANY-2324
Project: Tuscany
Issue Type: Bug
Components: Java SCA Axis Binding Extension
Reporter: Scott Kurz
Priority: Minor
If we take the following example where an inner component reference is
overridden in two ways
[
https://issues.apache.org/jira/browse/TUSCANY-2388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12604421#action_12604421
]
Scott Kurz commented on TUSCANY-2388:
-
This looks like it should work, since though
[
https://issues.apache.org/jira/browse/TUSCANY-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12603900#action_12603900
]
Scott Kurz commented on TUSCANY-2109:
-
Based on where our discussion ended up here
elder
Sent: Monday, June 09, 2008 4:49 AM
To: tuscany-dev
Subject: [NOTICE] Scott Kurz voted as Tuscany committer
The Tuscany PMC has voted for Scott Kurz to become a Tuscany committer.
Welcome Scott!
...ant
I think Gilbert is pointing out that the OSOA SCA WS binding spec says that
the TNS of the WSDL services/bindings/ports is supposed to be based on the
SCA names:
Base System URI for HTTP / Component Name / Service Name
While the portType should indeed be generated from the Java interface name
per
I'm getting this error:
Caused by: java.lang.ClassCastException: Cannot cast class
com.sun.tools.internal.xjc.addon.locator.SourceLocationAddOn to class
com.sun.tools.xjc.Plugin
when building the interface-java-jaxws module.
I noticed on the FAQ it says to make sure you're running with
Reporter: Scott Kurz
I'm having trouble reading a complex property from a file pointed to via the
property @file attr.
I'm using a JAXB to hold the prop value in my Java impl, but in looking at this
briefly in the debugger I think the problem might be in the DOM object before
[
https://issues.apache.org/jira/browse/TUSCANY-2377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Scott Kurz updated TUSCANY-2377:
Attachment: 2377.itest.example.diff
I didn't see an example for using XJC, so I just hand-gen'd
[
https://issues.apache.org/jira/browse/TUSCANY-2377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Scott Kurz updated TUSCANY-2377:
Attachment: 2377.itest.example.diff
Same file.. I meant to say it could be included in ASF
This was raised a few weeks ago here on this thread:
http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg31241.html
On Fri, Jun 6, 2008 at 4:16 PM, Gilbert Kwan [EMAIL PROTECTED] wrote:
Also, the namespace convention does not match to the section 2.3.2 of
WS Binding Spec V1.0, saying:
21, 2008 at 7:19 PM, Scott Kurz (JIRA)
tuscany-dev@ws.apache.org wrote:
[
https://issues.apache.org/jira/browse/TUSCANY-2332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Scott Kurz updated TUSCANY-2332:
Attachment
Maybe others are taking this for granted, but I think it would help to get
clear on why exactly we need a Tuscany SEI2WSDL/WSDL2SEI toolset, as opposed
to, say, leveraging and extending something like the CXF toolset.
I can see these arguments:
A) There are SCA-specific aspects of the artifacts
That 'generate-sdo' only generates the Java types from the schema types,
right?
It's the WSDL2Java which maps portType operations t**o Java methods and
(last I checked) our
W2J is the only tool which knows how to do this with an SDO databinding.
I'm not sure how useful the SDO-based J2W is,
Reporter: Scott Kurz
Though the Java annotations/API spec specifically says wrt WSDL- Java mapping:
The JAX-WS mappings are applied with the following restrictions:
• No support for holders
I'd like to suggest that we look into enabling such support anyway, as this
seems overly
[
https://issues.apache.org/jira/browse/TUSCANY-2332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Scott Kurz updated TUSCANY-2332:
Attachment: guessAndGreet.wsdl
reconsider non-support for Holders
Why do we need to be so strict in comparing interfaces?
Can't we argue essentially the same point in the case with we have a Java
client w/ reference w/ Java intf with a binding.ws?
So, following this logic, it's suggested that the NS calculated per-JAXWS
for the Java intf must match the
On Fri, May 16, 2008 at 1:04 PM, Simon Nash [EMAIL PROTECTED] wrote:
Scott Kurz wrote:
Why do we need to be so strict in comparing interfaces?
Can't we argue essentially the same point in the case with we have a Java
client w/ reference w/ Java intf with a binding.ws?
So, following
/browse/TUSCANY-2324
Project: Tuscany
Issue Type: Bug
Components: Java SCA Axis Binding Extension
Reporter: Scott Kurz
Priority: Minor
If we take the following example where an inner component reference is
overridden in two ways by the outer
Mike,
Just trying to use this issue to test/expand my own understanding of the
Tuscany databinding framework.
You're saying there's a problem with setting (resetting) the Axiom DB on the
IC obtained from the WebServiceBindingImpl.I'm just trying to understand
what the problem could be.
What
Raymond,
All of these sound interesting.
A minor point:
In making the databinding framework easy to use as a utility it would help
to refactor out the exception/fault matching code so it's not tied to an
interceptor, as other users of the Mediator may need to do the same routine.
Mike,
On Wed, May 14, 2008 at 9:41 AM, Mike Edwards
[EMAIL PROTECTED] wrote:
Scott,
Glad you've taken this out of the JIRA comments and on to the list -
easier to communicate this way ;-).
The point about the original code in Axis2ReferenceBindingProvider and
Axis2ServiceBindingProvider
, 2008 at 7:45 AM, Scott Kurz [EMAIL PROTECTED] wrote:
Mike,
On Wed, May 14, 2008 at 9:41 AM, Mike Edwards
[EMAIL PROTECTED] wrote:
Scott,
Glad you've taken this out of the JIRA comments and on to the list -
easier to communicate this way ;-).
The point about the original code
[
https://issues.apache.org/jira/browse/TUSCANY-2316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12596503#action_12596503
]
Scott Kurz commented on TUSCANY-2316:
-
The binding-ws-axis2 is overwriting
wondering...
I'm going to try to set this up before asking any more questions.
Thx, Scott
On Fri, May 9, 2008 at 10:49 AM, ant elder [EMAIL PROTECTED] wrote:
On Wed, May 7, 2008 at 3:59 PM, Scott Kurz [EMAIL PROTECTED] wrote:
I have a question on the JMS binding. If I were set up I'd just
I have a question on the JMS binding. If I were set up I'd just experiment,
but let me just ask
It looks to me like we're requiring the service client/impl to use OMElement
as its programming model (i.e. app databinding).
I say this looking at class JMSBindingReferenceBindingProvider and
Consider the use case where I start with a .componentType file, e.g.:
componentType xmlns=http://www.osoa.org/xmlns/sca/1.0;
service name=HelloWorld
interface.wsdl interface=
http://helloworld#wsdl.interface(HelloWorld) /
/service
/componentType
And I proceed to write a Java impl with
Kevin, Yee-Kang,
Did you envision creating a new API that would accept a component URI as
input,
e.g.:
ComponentContext getComponentContext(String componentURI);
Or were you talking about some sort of virtual component like Ant mentioned?
Scott
On Thu, Apr 24, 2008 at 10:49 AM, ant elder
[
https://issues.apache.org/jira/browse/TUSCANY-2113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12589777#action_12589777
]
Scott Kurz commented on TUSCANY-2113:
-
I'm sorry I don't have a test case handy
Affects Versions: Java-SCA-1.1
Reporter: Scott Kurz
Fix For: Java-SCA-Next
I think we should add guards to MediatorImpl.mediate() so that:
- We don't do the introspectType(source) if 'source' is null
- We simply return 'source' if 'targetDataType' is null
While
[
https://issues.apache.org/jira/browse/TUSCANY-2217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Scott Kurz updated TUSCANY-2217:
Attachment: 2217.patch
Some null guards needed in MediatorImpl
Raymond,
So, for 2085 for example, we have multiple different modules that, when
activated, may do an addDatabinding on the defaultDBExtensionPoint.
Eventually.. later...someone comes along and uses this to do an
introspectType. At that point the loadDataBindings() is done.
That all seems to
This question is especially for Raymond,
In trying to invoke the mediator from a service-side binding impl, I have a
need to get the wireTarget operation (to pass to the mediator).
I was wondering what the downside would be of caching the operation from the
service contract which I'd get in the
Project: Tuscany
Issue Type: Bug
Components: Java SCA Core Runtime
Reporter: Scott Kurz
Priority: Minor
I noticed this with a more complicated example.
To reproduce more simply maybe, go to the SVN dir: sca/itest/recursive
and modify
[
https://issues.apache.org/jira/browse/TUSCANY-2193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12585135#action_12585135
]
Scott Kurz commented on TUSCANY-2193:
-
I found the problem
[
https://issues.apache.org/jira/browse/TUSCANY-2189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Scott Kurz updated TUSCANY-2189:
Attachment: test.2189.jar
Sorry this doesn't exactly match the SCDL pasted it the JIRA text
Components: Java SCA Core Runtime
Reporter: Scott Kurz
Fix For: Java-SCA-Next
Attachments: test.2189.jar
Take something like this:
composite name=OuterComposite
component name=OuterCalculatorComponent
service name=OuterCalculatorService
Should this work?
composite name=OuterComposite
component name=OuterCalculatorComponent
service name=OuterCalculatorService
binding.ws wsdlElement=/
/service
implementation.composite name=calc:InnerComposite/
/component
/composite
composite
Hi,
I believe this check is only a constraint in determining if this WSDL
operation qualifies for wrapped mapping according to the JAX-WS spec. If
this does not hold we can still accept this WSDL, but we'll treat it as
nonwrapped and when mapping to Java, say, we'll use the nonwrapped style
[
https://issues.apache.org/jira/browse/TUSCANY-2084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12582302#action_12582302
]
Scott Kurz commented on TUSCANY-2084:
-
There's a similar issue for dynamic SDO
Project: Tuscany
Issue Type: Bug
Components: Java SCA Data Binding Runtime, Java SDO Implementation
Affects Versions: Java-SCA-1.1
Reporter: Scott Kurz
Fix For: Java-SCA-Next
Discussed in this thread:
http://www.mail-archive.com
comments.
Best Regards
- Alex
On Wed, Mar 5, 2008 at 11:25 PM, Simon Nash [EMAIL PROTECTED] wrote:
See inline.
Simon
Scott Kurz wrote:
One important difference if I understand correctly is the tool handles
SDOs
whereas the runtime
interface-wsdl-java2wsdl module only
: https://issues.apache.org/jira/browse/TUSCANY-2113
Project: Tuscany
Issue Type: Bug
Affects Versions: Java-SCA-1.1
Reporter: Scott Kurz
Fix For: Java-SCA-Next
There's a problem with how the fault matching in DTI uses the private
DTI.typesMatch
[
https://issues.apache.org/jira/browse/TUSCANY-2113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Scott Kurz updated TUSCANY-2113:
Description:
There's a problem with how the fault matching in DTI uses the private
[
https://issues.apache.org/jira/browse/TUSCANY-2113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Scott Kurz updated TUSCANY-2113:
Description:
There's a problem with how the fault matching in DTI uses the private
Thanks Simon that clears things up.
On Wed, Mar 19, 2008 at 10:00 AM, Simon Nash (JIRA)
tuscany-dev@ws.apache.org wrote:
[
https://issues.apache.org/jira/browse/TUSCANY-2033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12580378#action_12580378]
[
https://issues.apache.org/jira/browse/TUSCANY-2033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12579836#action_12579836
]
Scott Kurz commented on TUSCANY-2033:
-
I'm surprised we'd view Clemens' original
[
https://issues.apache.org/jira/browse/TUSCANY-2094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Scott Kurz updated TUSCANY-2094:
Attachment: JAXWSFaultExcMapper.patch
Would like to keep track of element name during fault
: Scott Kurz
Fix For: Java-SCA-1.2
Attachments: JAXWSFaultExcMapper.patch
In the JAXWSFaultExceptionMapper, we look at the @WebFault to capture the fault
element name.
It would be nice to capture during introspect this so it could be set into the
FaultException at wrap
I think this has been discussed before on this list.. but I'm not sure or
forget where we ended up.
In the case that you have a non-default binding on a component service
defined with an inner composite which
is in turn used as a component impl, what happens if the service is not
re-defined
[
https://issues.apache.org/jira/browse/TUSCANY-2084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Scott Kurz updated TUSCANY-2084:
Component/s: Java SDO Implementation
Java SCA Data Binding Runtime
For awhile I was disabling the three xxx2DataObject transformers from being
called during intermediate transfroms by using the supported mechanism for
marking the private,
e.g.:
org.apache.tuscany.sca.databinding.sdo.String2DataObject;source=
SCA Data Binding Runtime
Affects Versions: Java-SCA-1.1
Reporter: Scott Kurz
Priority: Minor
Fix For: Java-SCA-Next
Get an exception like the following,
java.util.ConcurrentModificationException
at java.util.AbstractList$SimpleListIterator.next(Unknown
One important difference if I understand correctly is the tool handles SDOs
whereas the runtime
interface-wsdl-java2wsdl module only handles POJO types.
I think the runtime code basically relies on Axis2's Java-XSD mapping,
which I don't think would
fully honor JAXB annotations in the Java as it
JXAB.
But for tools\java2wsdl, it NOT easy since it use different approache.
-Alex
On Wed, Mar 5, 2008 at 10:09 PM, Scott Kurz [EMAIL PROTECTED]
wrote:
One important difference if I understand correctly is the tool handles
SDOs
whereas the runtime
interface-wsdl-java2wsdl module
I think we have another case to deal with in bindings like the Axis2
binding, which is the case that the user provides a portType on
interface.wsdl
without a full port.
So the SCDL would look like:
component name=JAXBTestComponent1
implementation.java ...
service...
Question:
Way back in October in r589154 SDODataBinding.introspect was changed to
propagate the Java dflt elem QName into the XMLType logical with code that
looks like:
Object logical = dataType.getLogical();
if (logical instanceof XMLType) {
elementName =
[
https://issues.apache.org/jira/browse/TUSCANY-1679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Scott Kurz updated TUSCANY-1679:
Summary: PBVInvoker doesn't handle checked/business excs (was: PBVInvoker
always uses service
[
https://issues.apache.org/jira/browse/TUSCANY-1679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12570742#action_12570742
]
Scott Kurz commented on TUSCANY-1679:
-
The implications of some other discussions
Yes I can envision some useful transforms which wrapper/unwrapper data
formats without doing copies.
That raises the question of how to turn off PBVInterceptor dynamically.
I guess I hadn't given this enough thought before, since actually I'd
like to be able to do the same from the binding
I can see the advantages of registering in init.
I'd heard that import.sdo for statics was deprecated but hadn't
picked up we were trying to say it was deprecated for dynamic too.
I must have missed that...
Scott
-
To
-
From: Scott Kurz [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Wednesday, February 20, 2008 9:48 AM
Subject: Re: Bypassing unnecessary transforms by Tuscany databinding
framework
Yes I can envision some useful transforms which wrapper/unwrapper data
formats without doing copies
Responses inline...thanks
OK, I guess I didn't understand what you did after all.
I'm not sure why we are looking at the client side and the reference
binding invoker?Is there even
a chain we care about on the client side? Doesn't the chain consist
of a path from
I meant to say:
Given my view I don't see it's relevance ON THE CLIENT SIDE
On Feb 20, 2008 2:32 PM, Scott Kurz [EMAIL PROTECTED] wrote:
Responses inline...thanks
OK, I guess I didn't understand what you did after all.
I'm not sure why we are looking at the client side
Hi Raymond, Sebastien,
Sorry I dropped off of the discussion for awhile. I took a look at
the r628163 code.
Let me see if I'm understanding this correctly:
When an Invoker implements PassByValueAware.allowsPassByReference()
and returns 'true', it means exactly this:
I know that, on this
Wang,
I'm guessing the problem is probably that you need to register your
app types with the appropriate context established by the Tuscany
runtime.
Tuscany typically does this automatically, now, for static SDO. For
dynamic SDO (i.e. DataObject), you would currently put something like
this in
[
https://issues.apache.org/jira/browse/TUSCANY-2042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12567848#action_12567848
]
Scott Kurz commented on TUSCANY-2042:
-
It is looking more like an Axis2 versioning
[
https://issues.apache.org/jira/browse/TUSCANY-2042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12567709#action_12567709
]
Scott Kurz commented on TUSCANY-2042:
-
I recreated this at the same time as stepping
There's two jars with WSDL4J relevant to the 6.1 appserver runtime:
WAS\plugins\com.ibm.ws.runtime_6.1.0.jar
WAS\plugins\org.apache.axis2_6.1.0.jar
The rest are relevant for tooling and client envs.
The first of those has some version WSDL4J 1.5 and the latter 1.6.
So you manually patched
Ant,
There is more than one version of WSDL4J in the WAS 6.1 image.
You're probably getting the wrong one.
Generally speaking WAS 6.1 uses OSGI bundle manifests and a special
OSGi-enabled classloader network to load the
right target class starting from a given source classloader. There
are
[
https://issues.apache.org/jira/browse/TUSCANY-2042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12567709#action_12567709
]
scottkurz edited comment on TUSCANY-2042 at 2/11/08 9:16 AM:
--
, 2008 3:55 AM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:
Scott Kurz wrote:
When you wrote:
- The generator should use the databinding metadata (including any
knowledge of handwritten XSD representing the business data and
generation capabilities like the SDO XSDGenerator) to generate
On Feb 3, 2008 5:01 PM, Mike Edwards [EMAIL PROTECTED] wrote:
Folks,
It is important to remember that when an interface is specified EITHER
as some non-WSDL interface type (eg Java interface) OR where it is
specified as WSDL, the FINAL WSDL that is necessary for a deployed (web)
service may
Sebastien,
When you wrote:
- The generator should use the databinding metadata (including any
knowledge of handwritten XSD representing the business data and
generation capabilities like the SDO XSDGenerator) to generate proper
XSD in the WSDL.
How were you thinking a particular XSD would be
I was looking over the runtime Java2WSDLHelper code to get some
understanding of it.
After we build the WSDL with the call to: builder.generateWSDL();
I was wondering what we're doing post-gen to the WSDL types section?
What's the code calling readInlineSchemas() doing?
Is that code in there
plug in their own patterns.
Thanks,
Raymond
- Original Message -
From: Scott Kurz [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Thursday, January 24, 2008 3:01 PM
Subject: Re: Exception-Fault mapping
Raymond,
Thanks for organizing this discussion much better
should wrap the fault into a
ServiceRuntimeException.
Thanks,
Raymond
- Original Message -
From: Scott Kurz [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Thursday, January 10, 2008 5:14 PM
Subject: Exception-Fault mapping
A few months back, I wrote up a proposal
The binding-feed code suggests a way to deal with JIRAs 1678,1680.
That is, the mediator is called directly from within the binding
implementation,
rather than relying on the DBInterceptor being set up on the wire at
Composite start time with a static DB transform established at that
time.
A key
Right... for specific binding(s) there might be a co-located
optimization (whereas maybe other bindings require
some sort of normalized data format).However the question of where
the target service is co-located or not is clearly
not a binding-specific question to answer.
As far as
the same maybe I can do PBR)
* is target annotated with @AllowsPBR
And again, I'm ignorant to what extent this is already possible...
Scott
On Jan 23, 2008 1:36 PM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:
Scott Kurz wrote:
The binding-feed code suggests a way to deal with JIRAs
Issue Type: Bug
Components: Java SCA Assembly Model
Affects Versions: Java-SCA-1.0.1
Reporter: Scott Kurz
Priority: Minor
Fix For: Java-SCA-1.1
Consider the following two SCDL files, a top-level SCDL with a component
implemented in a 2nd SCDL
Raymond,
Can I ask a question about this?
For static SDOs (Ignoring the wrapper types which have this problem),
we're only registering the SDOs with the Composite HelperContext
during transformation, right?
During introspection the SDODataBinding.introspect calls
TypeHelper.getType(Class) but
[
https://issues.apache.org/jira/browse/TUSCANY-1938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12559236#action_12559236
]
Scott Kurz commented on TUSCANY-1938:
-
It works now (operation is treated as 'wrapped
the correct fix should be:
if (edge.isPublic() || edge.getTargetVertex() == target) {
...
}
Thanks,
Raymond
- Original Message -
From: Scott Kurz [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Wednesday, January 09, 2008 2:23 PM
Subject: Re: Does the public/private
I can't remember if I brought this up a few months back or not...
but I question whether in DataTransformationInterceptor we really need to go
as far as to match the TypeInfo of the source and target fault DataType
logicals for XMLTypes.
In DataTransformationInterceptor.typesMatch() we do:
A few months back, I wrote up a proposal for decoupling the fault
databinding from the way that the exception maps to a fault
which would among other things get the exception handlers out of the
introspection business.
The mail is here:
Can we discuss the issue mentioned in:
https://issues.apache.org/jira/browse/TUSCANY-1938
Does anyone agree with my opinion that the interpretation in the JAX-WS RI
toolset is better than the Tuscany interpretation?
(Though I understand Raymond has disagreed in the past.)
Thanks,
Scott
it in TUSCANY-1938.
Thanks,
Raymond
- Original Message -
From: Scott Kurz [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Wednesday, January 09, 2008 8:58 AM
Subject: JAX-WS spec interpretation question re: doc-lit-wrapped? WSDLs
with
wrapper elems with non-substitution-group
I have some code around the r603995 level... and I noticed the following
transformer chain when the impl uses JAXB with the WS binding (using AXIOM
DB):
org.apache.tuscany.sca.databinding.jaxb.JAXB2Node
org.apache.tuscany.sca.databinding.sdo.Node2DataObject
to something else ONLY
if this is the first transform outbound I also want to convert from
something else to SDO ONLY
if this is the last transform inbound, i.e. the transform resulting in the
ultimate target DB.
Does this sound reasonable?
Scott
On Jan 9, 2008 3:19 PM, Scott Kurz [EMAIL
I noticed class,
org.apache.tuscany.sca.databinding.jaxb.BeanXMLStreamReaderImpl is invoking
a constructor of com.sun.xml.bind.v2.runtime.JAXBContextImpl:
JAXBContextImpl context =
new JAXBContextImpl(classes, null, Collections.Class, Class
emptyMap(), null, false, reader,
://issues.apache.org/jira/browse/TUSCANY-1938
Project: Tuscany
Issue Type: Bug
Components: Java SCA Core Runtime
Affects Versions: Java-SCA-1.0
Reporter: Scott Kurz
The JAX-WS Spec, Sec. 2.3.1.2, makes the following confusing statement in
defining the WSDL
[
https://issues.apache.org/jira/browse/TUSCANY-1938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Scott Kurz updated TUSCANY-1938:
Attachment: helloworld.wsdl
doc-lit-wrapped WSDLs with wrapper elems with non-substitution
Issue Type: Bug
Reporter: Scott Kurz
Priority: Minor
I found another case where the JDKInvocationHandler.match() doesn't handle WSDL
interfaces.
Earlier problems in this area were:
https://issues.apache.org/jira/browse/TUSCANY-1342
https://issues.apache.org/jira/browse
: Tuscany
Issue Type: Bug
Components: Java SCA Tools, Java SDO Tools
Affects Versions: Java-SCA-1.0, Java-SCA-1.0.1
Reporter: Scott Kurz
Priority: Trivial
The fact that: TuscanyWSDLTypesGenerator .createSchemaTypeForMethodPart
on line 267 calls
[
https://issues.apache.org/jira/browse/TUSCANY-1902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Scott Kurz updated TUSCANY-1902:
Fix Version/s: (was: Java-SCA-1.0.1)
Input2InputTransformer doesn't handle null input going
Type: Bug
Components: Java SCA Data Binding Runtime
Affects Versions: Java-SCA-1.0
Reporter: Scott Kurz
Priority: Minor
Fix For: Java-SCA-1.0.1
I get the following:
java.lang.NullPointerException
[
https://issues.apache.org/jira/browse/TUSCANY-1681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Scott Kurz updated TUSCANY-1681:
Attachment: 1681.patch
Well, let me push the issue a bit by at least submitting a patch
1 - 100 of 248 matches
Mail list logo
