Re: [SDO] questions about support for Enumeration facet
Amita,
I think Frank's note in this thread is key to the solution, in that the
line ...
return SDOUtil.createFromString(property.getType(), value);
will create a List if the type of the Property is set to
commonj.sdo{Strings}
Regards, Kelvin.
On 14/12/2007, Amita Vadhavkar [EMAIL PROTECTED] wrote:
Tried to do little more analysis to see what is the way to reach
ExtendedMetadata from DataObjectUtil. Please see the findings below.
DataObjectUtil.getMetaObjectInstanceProperty(EModelElement, Property) can
be
reached from
AttributeImpl(EAttributeImpl), ClassImpl(EClassImpl),
DataTypeImpl(EDataTypeImpl), ReferenceImpl(EReferenceImpl).
Below is the inheritance for EAttributeImpl -
java.lang.Object
extended by org.eclipse.emf.common.notify.impl.BasicNotifierImpl
extended by org.eclipse.emf.ecore.impl.BasicEObjectImpl
extended by org.eclipse.emf.ecore.impl.EObjectImpl
extended by org.eclipse.emf.ecore.impl.FlatEObjectImpl
extended by
org.eclipse.emf.ecore.impl.EModelElementImpl**
extended by
org.eclipse.emf.ecore.impl.ENamedElementImpl
extended by
org.eclipse.emf.ecore.impl.ETypedElementImpl
extended by
org.eclipse.emf.ecore.impl.EStructuralFeatureImpl
extended by
org.eclipse.emf.ecore.impl.EAttributeImpl
Below is the inheritance for EClassImpl -
java.lang.Object
extended by org.eclipse.emf.common.notify.impl.BasicNotifierImpl
extended by org.eclipse.emf.ecore.impl.BasicEObjectImpl
extended by org.eclipse.emf.ecore.impl.EObjectImpl
extended by org.eclipse.emf.ecore.impl.FlatEObjectImpl
extended by
org.eclipse.emf.ecore.impl.EModelElementImpl**
extended by
org.eclipse.emf.ecore.impl.ENamedElementImpl
extended by
org.eclipse.emf.ecore.impl.EClassifierImpl
extended by
org.eclipse.emf.ecore.impl.EClassImpl
Below is the inheritance for EDataTypeImpl -
java.lang.Object
extended by org.eclipse.emf.common.notify.impl.BasicNotifierImpl
extended by org.eclipse.emf.ecore.impl.BasicEObjectImpl
extended by org.eclipse.emf.ecore.impl.EObjectImpl
extended by org.eclipse.emf.ecore.impl.FlatEObjectImpl
extended by
org.eclipse.emf.ecore.impl.EModelElementImpl**
extended by
org.eclipse.emf.ecore.impl.ENamedElementImpl
extended by
org.eclipse.emf.ecore.impl.EClassifierImpl
extended by
org.eclipse.emf.ecore.impl.EDataTypeImpl
Below is the inheritance for EReferenceImpl -
java.lang.Object
extended by org.eclipse.emf.common.notify.impl.BasicNotifierImpl
extended by org.eclipse.emf.ecore.impl.BasicEObjectImpl
extended by org.eclipse.emf.ecore.impl.EObjectImpl
extended by org.eclipse.emf.ecore.impl.FlatEObjectImpl
extended by
org.eclipse.emf.ecore.impl.EModelElementImpl**
extended by
org.eclipse.emf.ecore.impl.ENamedElementImpl
extended by
org.eclipse.emf.ecore.impl.ETypedElementImpl
extended by
org.eclipse.emf.ecore.impl.EStructuralFeatureImpl
extended by
org.eclipse.emf.ecore.impl.EReferenceImpl
In this heirarchy, DataObjectUtil.getMetaObjectInstanceProperty() sticks
to
EModelElementImpl as is it common in all these 4 cases.
But in case of EDataTypeImpl there is further hierarchy which is useful
when
it comes to facets - which is EClassifierImpl.
EClassifierImpl has getExtendedMetaData() returning
BasicExtendedMetaData.EClassifierExtendedMetaData. This one has all the
methods
for getting different facet informations like - java.util.List
java.lang.String getEnumerationFacet() , int getMinLengthFacet()
and so on.
So a way out to get the enum facet value as a list can be - in
DataObjectUtil.getMetaObjectInstanceProperty() - do as below -
if(metaObject instanceof EDataTypeImpl/EClassifierImpl){
if(property.getName().equals(enumeration)) {
List enumVals =
((EDataTypeImpl)metaObject).getExtendedMetaData().getEnumerationFacet();
return enumVals;
}
}
Same can be the way to get value of getPatternFacet() as this is the only
other facet which returns a list (ref
emfBasicExtendedMetaData.EClassifierExtendedMetaData).
For all other facets as they return a single value, the current SDO code
may
be enough {OR for all facets on EDataTypeImpl, we can
reach ((EDataTypeImpl)metaObject).getExtendedMetaData() and call
patricular
getFacet methods, not sure if this is required - suggestions?}
DataObjectUtil.getMetaObjectInstanceProperties() can remain unchanged.
With the above change in
Re: [Java SDO] What should we be attacking?
Thanks Rajini, I propose we hold on until January in the hope that you will be able to tackle this. Many thanks, Kelvin. On 11/12/2007, Rajini Sivaram [EMAIL PROTECTED] wrote: Kelvin, I am busy until Christmas with the SCA-OSGi work, but I will try and look at the OSGi-enablement of SDO early in the new year. At the moment I can't promise anything, but from the notes that you produced about classloading, and the code and comments from Bert, I think there is enough information to prototype an implementation. I will update the list in the new year after I take a more detailed look. Thank you... Regards, Rajini On 12/10/07, kelvin goodson [EMAIL PROTECTED] wrote: I'd kind of hoped to be in a position to have a release before the end of the year. The JIRA query [1] shows that we have 34 JIRAs in resolved state with a fix version of SDO-Next, but I think it would be good to get the OSGi issues dealt with before a release. Thoughts? Kelvin. [1] https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truepid=12310210status=5status=6component=12311542component=12310660component=12310973component=12310802fixfor=12312262resolution=1sorter/field=issuekeysorter/order=DESCsorter/field=componentssorter/order=ASCsorter/field=updatedsorter/order=DESC On 29/11/2007, kelvin goodson [EMAIL PROTECTED] wrote: David, thanks for the fixes. I'll apply them as soon as I can get to them. I've been away unwell for most of the last weeks so I have some catching up to do. Anything you can do to reduce the JIRA backlog further would be great, thanks. Kelvin. On 29/11/2007, David Adcox [EMAIL PROTECTED] wrote: Kelvin, I have some free cycles, so I'd like to help knock some things off this list for you. I've gone ahead and contributed a patch for 1483. I'll address 1545 as well. I believe that 1384 is already done. On Nov 20, 2007 6:36 AM, kelvin goodson [EMAIL PROTECTED] wrote: What should we be concentrating our efforts on in SDO Java. I posted a while back to suggest we think about the content of a next release. We've had a few fixes go in recently, but I'd like to see more consideration of release content before we crank the handle. It would be great to see a balance of new features and bug fixes. For my part I want to get back to ... TUSCANY-1527Allow for custom data binding of DataObjects in a Swing UI TUSCANY-1493Snapshot mapping framework to convert DataObjects to and from Java objects as soon as I can. And I believe that at least 1527 can move beyond proof of concept in my sandbox, and become part of the trunk. I've been taking a pass through the SDO java JIRA backlog, and seeing from my perspective what's simple / tricky / big / high priority etc, etc. Of course simplicity is in the eye of the beholder, for example, I don't view the OSGi topic as simple as I don't have experience there, but someone out there may find it so; if so please speak up. The same goes for priority, etc. As you might imagine, in my estimation there are no simple high priority JIRAs left, but there are a few simple medium priority ones, or simple low priority ones that would be good to just get out of the way. These are Simple Starters === TUSCANY-1360New SDOUtil: Getting the enumeration facet TUSCANY-1178DynamicTypesFromSchemaTestCase expecting *Object types to be created TUSCANY-1263XMLEqualityChecker too strict TUSCANY-1359New SDOUtil: Upper and lower bound on properties where 'isMany' is true TUSCANY-1384SequenceAddOpenTest.setUp() needs to check if type exists before creating it TUSCANY-1545Change default XML encoding to UTF-8. TUSCANY-1659SDO DateConversion test cases fail under linux Particular Skills JIRAs = For anyone with JavaJet experience there's TUSCANY-1483Static SDO generator: problem with elements named internal* which would be simple For someone with maven build experience there TUSCANY-257 recently added file Interface2JavaGenerator.javais not compatible with JDK 1.4 For someone with Grobu-Utils and maven skills there's ... TUSCANY-1182Add multi-threaded test case for data object creation Someone with Axis2 skills TUSCANY-1038SDO databinding for Axis2 (This may be better done within the Axis2 project) OSGi Skills TUSCANY-1293SDO does not work with OSGi Biting off something a bit Bigger For somebody wanting something a bit bigger to take on there's TUSCANY-1192Preserve demand created global properties
Re: What is Tuscany?
Folks, Let me put my oar in here. I'll start first with SCA and ESBs and then move to discuss Tuscany. Let's start with a controversial statement: SCA is a programming model for ESBs Daniel made some statements about what an ESB is - I do agree that this is ill-defined (purposely so, from some of the vendors, I believe). I think that the following are true of ESBs: - virtualizes services and service invocations: makes their actual location and actual protocol irrelevant - provide (dynamic) mapping between a service invocation and the target service used - provide discovery and selection of service(s) meeting specified criteria: may include choices based on QoS or on business criteria There may be other aspects too, but these seem to cover the bulk of the capabilities. SCA provides a way of describing service consumers and service providers in a way that is consumable by an ESB. SCA describes the consuming components and provides metadata for each service reference. SCA describes the provider components and has metadata for each service offered. The connection from a consumer to a provider can: - be left totally open (autowire), in which case the runtime infrastructure is responsible for finding suitable target services - be specified separately from consumer and provider components (separate wires), in which case the wires represent static connections made by the ESB infrastructure - be specified as part of the consumer, but potentially only by indicating the identity of the target, rather than anything to do with its location (ie component/service rather than some binding specific endpoint address) These methods all allow for the activities of an ESB: - services and service references are virtualized. Actual locations and actual protocols can be decided at runtime or bound very late in the deployment process. An SCA component can be distributed onto a grid-style runtime (there are products such as Paremus' Infiniflow that do this) - dynamic connections are possible (autowire) - where consumers must be mapped to providers, SCA can model the activities of the mediation between them - mediations can be modelled as service components of some mediation type (eg XSLT transform) - dynamic selection of target services can likewise be modelled as a component of some type sitting between consumer and provider (eg rules component) Tuscany can be used to do some of these things. Tuscany on its own can be configured with appropriate components. Alternatively, Tuscany can be used with an ESB like ServiceMix or Synapse, using some of the mediation capabilities of those systems to provide implementations of the mediation components. Hope that this helps the debate. Yours, Mike. Daniel Stefan Haischt wrote: On Dec 14, 2007 10:55 PM, Simon Nash [EMAIL PROTECTED] wrote: ESB is much (mis)used as a marketing term. By those standards, Tuscany is probably one already :-) But we'd probably want to have some clear technical idea of what an ESB is before we decide whether we want to put Tuscany under the (increasingly crowded) ESB umbrella. I think ESB should be recognized as an architectural pattern. If there is rather much confusion about what an ESB is, this may indicate that the pattern isn't well defined. Otherwise it would be more or less easy to determine whether Tuscany fulfills what the pattern is specifying, no? Somebody told me recently that ESBs are about virtualized service endpoints. So there's a layer somewhere that can map virtual endpoints to real endpoints, and can change the real endpoints even though the virtual endpoints (as specified by application code) stay the same. Hummm I've been told that service virtualization is a SOA principle thus isn't tightly coupled to an ESB. Quote: There has been talk about dynamically provisioned services for years now. The problem is that even ESBs bind the service invocation too tightly to the service implementation. [1] It's even more interesting what will be virtualized :) * The actual location of the service (i.e. the FQDN or an IP address) * The service protocol (OpenESB also supports server-side virtualization of the service protocol [3]) * I was also once told that virtualization will be used to abstract different service implementations and thus the requestor may provide certain quality of service criteria to the virtual service endpoint which then delegates the request to the appropriate service according to the QoS criteria. * etc. Refs: [1] http://rourkem.com/soa/matt-quinn-on-service-virtualization.html [2] http://websphere.sys-con.com/read/467329.htm (Unifying Grid Virtualization, SaaS and SOA) [3] http://blogs.sun.com/tientien/entry/web_service_virtualization - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1936) Can't rerun mvn on wsdl2java unles clean done first
Can't rerun mvn on wsdl2java unles clean done first
---
Key: TUSCANY-1936
URL: https://issues.apache.org/jira/browse/TUSCANY-1936
Project: Tuscany
Issue Type: Bug
Components: Java SCA Tools
Affects Versions: Java-SCA-1.0.1
Environment: Windows XP
Reporter: Simon Nash
Priority: Minor
Fix For: Java-SCA-Next
To recreate this problem, do the following:
1. change directory to the module tools/wsdl2java
2. run mvn clean
3. run mvn
4. run mvn again
The second mvn fails with the error shown below. For most modules, it is OK to
run mvn a second time, and this just reruns the tests.
[INFO] -
---
[INFO] Building Apache Tuscany SCA WSDL2Java Tool
[INFO]task-segment: [install]
[INFO] -
---
[INFO] [build-helper:add-test-source {execution: add-test-source}]
[INFO] Test Source directory: H:\tuscany58\sca\tools\wsdl2java\target\sdo-source
added.
[INFO] Test Source directory: H:\tuscany58\sca\tools\wsdl2java\target\wsdl2java-
source added.
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[WARNING]
Artifact com.sun.xml.bind:jaxb-impl:jar:2.1.4:runtime retains local scop
e 'runtime' overriding broader scope 'compile'
given by a dependency. If this is not intended, modify or remove the loc
al scope.
[WARNING]
Artifact xerces:xercesImpl:jar:2.8.1:runtime retains local scope 'runtim
e' overriding broader scope 'compile'
given by a dependency. If this is not intended, modify or remove the loc
al scope.
[INFO] [compiler:compile]
[INFO] Nothing to compile - all classes are up to date
[INFO] [tuscany-sdo:generate {execution: generate-sdo}]
[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
[INFO] Compiling 4 source files to H:\tuscany58\sca\tools\wsdl2java\target\test-
classes
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Compilation failure
H:\tuscany58\sca\tools\wsdl2java\target\wsdl2java-source\org\apache\tuscany\tool
s\wsdl2java\generate\account\DocTestPortType.java:[26,24] cannot find symbol
symbol : class SingleTag
location: package org.soapinterop
H:\tuscany58\sca\tools\wsdl2java\target\wsdl2java-source\org\apache\tuscany\tool
s\wsdl2java\generate\account\DocTestPortType.java:[25,31] cannot find symbol
symbol : class SingleTag
location: package org.soapinterop
H:\tuscany58\sca\tools\wsdl2java\target\wsdl2java-source\org\apache\tuscany\tool
s\wsdl2java\generate\account\DocTestPortType.java:[35,24] cannot find symbol
symbol : class SimpleDocument1
location: package org.soapinterop
H:\tuscany58\sca\tools\wsdl2java\target\wsdl2java-source\org\apache\tuscany\tool
s\wsdl2java\generate\account\DocTestPortType.java:[34,31] cannot find symbol
symbol : class SimpleDocument1
location: package org.soapinterop
H:\tuscany58\sca\tools\wsdl2java\target\wsdl2java-source\org\apache\tuscany\tool
s\wsdl2java\generate\account\DocTestPortType.java:[44,24] cannot find symbol
symbol : class ComplexDocument
location: package org.soapinterop
H:\tuscany58\sca\tools\wsdl2java\target\wsdl2java-source\org\apache\tuscany\tool
s\wsdl2java\generate\account\DocTestPortType.java:[43,31] cannot find symbol
symbol : class ComplexDocument
location: package org.soapinterop
H:\tuscany58\sca\tools\wsdl2java\target\wsdl2java-source\org\apache\tuscany\tool
s\wsdl2java\generate\account\AccountService.java:[33,58] package org.apache.tusc
any.samples.bigbank.account does not exist
H:\tuscany58\sca\tools\wsdl2java\target\wsdl2java-source\org\apache\tuscany\tool
s\wsdl2java\generate\account\AccountService.java:[43,58] package org.apache.tusc
any.samples.bigbank.account does not exist
H:\tuscany58\sca\tools\wsdl2java\target\wsdl2java-source\org\apache\tuscany\tool
s\wsdl2java\generate\account\AccountService.java:[69,58] package org.apache.tusc
any.samples.bigbank.account does not exist
H:\tuscany58\sca\tools\wsdl2java\target\wsdl2java-source\org\apache\tuscany\tool
s\wsdl2java\generate\account\InsufficientFundsFault.java:[8,31] package com.bigb
ank.account does not exist
H:\tuscany58\sca\tools\wsdl2java\target\wsdl2java-source\org\apache\tuscany\tool
s\wsdl2java\generate\account\InsufficientFundsFault.java:[10,69] package com.big
bank.account does not exist
H:\tuscany58\sca\tools\wsdl2java\target\wsdl2java-source\org\apache\tuscany\tool
s\wsdl2java\generate\account\InsufficientFundsFault.java:[15,69] package com.big
bank.account does not exist
H:\tuscany58\sca\tools\wsdl2java\target\wsdl2java-source\org\apache\tuscany\tool
[jira] Updated: (TUSCANY-1936) Can't rerun mvn on wsdl2java unless clean done first
[
https://issues.apache.org/jira/browse/TUSCANY-1936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Nash updated TUSCANY-1936:
Summary: Can't rerun mvn on wsdl2java unless clean done first (was: Can't
rerun mvn on wsdl2java unles clean done first)
Can't rerun mvn on wsdl2java unless clean done first
Key: TUSCANY-1936
URL: https://issues.apache.org/jira/browse/TUSCANY-1936
Project: Tuscany
Issue Type: Bug
Components: Java SCA Tools
Affects Versions: Java-SCA-1.0.1
Environment: Windows XP
Reporter: Simon Nash
Priority: Minor
Fix For: Java-SCA-Next
To recreate this problem, do the following:
1. change directory to the module tools/wsdl2java
2. run mvn clean
3. run mvn
4. run mvn again
The second mvn fails with the error shown below. For most modules, it is OK
to run mvn a second time, and this just reruns the tests.
[INFO]
-
---
[INFO] Building Apache Tuscany SCA WSDL2Java Tool
[INFO]task-segment: [install]
[INFO]
-
---
[INFO] [build-helper:add-test-source {execution: add-test-source}]
[INFO] Test Source directory:
H:\tuscany58\sca\tools\wsdl2java\target\sdo-source
added.
[INFO] Test Source directory:
H:\tuscany58\sca\tools\wsdl2java\target\wsdl2java-
source added.
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[WARNING]
Artifact com.sun.xml.bind:jaxb-impl:jar:2.1.4:runtime retains local
scop
e 'runtime' overriding broader scope 'compile'
given by a dependency. If this is not intended, modify or remove the
loc
al scope.
[WARNING]
Artifact xerces:xercesImpl:jar:2.8.1:runtime retains local scope
'runtim
e' overriding broader scope 'compile'
given by a dependency. If this is not intended, modify or remove the
loc
al scope.
[INFO] [compiler:compile]
[INFO] Nothing to compile - all classes are up to date
[INFO] [tuscany-sdo:generate {execution: generate-sdo}]
[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
[INFO] Compiling 4 source files to
H:\tuscany58\sca\tools\wsdl2java\target\test-
classes
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Compilation failure
H:\tuscany58\sca\tools\wsdl2java\target\wsdl2java-source\org\apache\tuscany\tool
s\wsdl2java\generate\account\DocTestPortType.java:[26,24] cannot find symbol
symbol : class SingleTag
location: package org.soapinterop
H:\tuscany58\sca\tools\wsdl2java\target\wsdl2java-source\org\apache\tuscany\tool
s\wsdl2java\generate\account\DocTestPortType.java:[25,31] cannot find symbol
symbol : class SingleTag
location: package org.soapinterop
H:\tuscany58\sca\tools\wsdl2java\target\wsdl2java-source\org\apache\tuscany\tool
s\wsdl2java\generate\account\DocTestPortType.java:[35,24] cannot find symbol
symbol : class SimpleDocument1
location: package org.soapinterop
H:\tuscany58\sca\tools\wsdl2java\target\wsdl2java-source\org\apache\tuscany\tool
s\wsdl2java\generate\account\DocTestPortType.java:[34,31] cannot find symbol
symbol : class SimpleDocument1
location: package org.soapinterop
H:\tuscany58\sca\tools\wsdl2java\target\wsdl2java-source\org\apache\tuscany\tool
s\wsdl2java\generate\account\DocTestPortType.java:[44,24] cannot find symbol
symbol : class ComplexDocument
location: package org.soapinterop
H:\tuscany58\sca\tools\wsdl2java\target\wsdl2java-source\org\apache\tuscany\tool
s\wsdl2java\generate\account\DocTestPortType.java:[43,31] cannot find symbol
symbol : class ComplexDocument
location: package org.soapinterop
H:\tuscany58\sca\tools\wsdl2java\target\wsdl2java-source\org\apache\tuscany\tool
s\wsdl2java\generate\account\AccountService.java:[33,58] package
org.apache.tusc
any.samples.bigbank.account does not exist
H:\tuscany58\sca\tools\wsdl2java\target\wsdl2java-source\org\apache\tuscany\tool
s\wsdl2java\generate\account\AccountService.java:[43,58] package
org.apache.tusc
any.samples.bigbank.account does not exist
H:\tuscany58\sca\tools\wsdl2java\target\wsdl2java-source\org\apache\tuscany\tool
s\wsdl2java\generate\account\AccountService.java:[69,58] package
org.apache.tusc
any.samples.bigbank.account does not exist
H:\tuscany58\sca\tools\wsdl2java\target\wsdl2java-source\org\apache\tuscany\tool
s\wsdl2java\generate\account\InsufficientFundsFault.java:[8,31] package
com.bigb
ank.account does not exist
Binding names
Following on from the thread about identifying binding targets [1] the SCA
assembly specification (lines 2319-2327) describes a binding name as being
unique within a reference or service. If a binding name is not specified in
the SCDL this is not the case currently. I.e the each binding adopts the
name of the reference or service to which it belongs. This makes
identification of an individual binding difficult, for example, if you
wanted to retrieve the details of an individual binding artifact from the
live model. In the particular case where a default is chosen for a binding
name (as opposed to a name having been specified) how about we do the
following:
References - Append the name of the target service to the end of the
reference name to form the binding name
Services - Append a number to the end of the binding name based on the
position of the binding name in the bindings list.
There are a couple of places that use the binding name that could do with a
little explanation if anyone knows the details.
CompositeActivator.addReferenceWire()
for (Binding binding : callbackService.getBindings()) {
// first look for a callback binding whose name matches the
reference binding name
if (binding.getName().equals(refBinding.getName())) {
callbackBinding = binding;
break;
}
}
Not sure why this is checking that the callback binding name matches the
reference binding name before choosing a binding.Under what circumstances
will these names either match or not match.
There is also something similar going on in
CallbackReferenceImpl.selectCallbackWire()
// no exact match, so find callback binding with same name as
service binding
EndpointReference to = msgContext.getTo();
if (to == null) {
//FIXME: need better exception
throw new RuntimeException(Destination for forward call is not
available);
}
for (RuntimeWire wire : wires) {
if
(wire.getSource().getBinding().getName().equals(to.getBinding().getName()))
{
//FIXME: need better way to represent dynamic wire
if (wire.getTarget().getURI().equals(/)) { // dynamic wire
//FIXME: avoid doing this for genuine dynamic wires
return cloneAndBind(msgContext, wire);
}
//FIXME: no dynamic wire, so should attempt to create a
static wire
}
}
Again it's filtering bindings based on binding name but it's not clear what
the circumstances are where this match will be successful.
Regards
Simon
[1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg26380.html
Re: Binding names
Simon,
One comment inline.
Yours, Mike.
Simon Laws wrote:
Following on from the thread about identifying binding targets [1] the SCA
assembly specification (lines 2319-2327) describes a binding name as being
unique within a reference or service. If a binding name is not specified in
the SCDL this is not the case currently. I.e the each binding adopts the
name of the reference or service to which it belongs. This makes
identification of an individual binding difficult, for example, if you
wanted to retrieve the details of an individual binding artifact from the
live model. In the particular case where a default is chosen for a binding
name (as opposed to a name having been specified) how about we do the
following:
References - Append the name of the target service to the end of the
reference name to form the binding name
Services - Append a number to the end of the binding name based on the
position of the binding name in the bindings list.
Why treat references differently to services? Why not use the idea of
appending a number in both cases? What about the case where the same
binding on a reference gets used for more than one target service?
There are a couple of places that use the binding name that could do with a
little explanation if anyone knows the details.
CompositeActivator.addReferenceWire()
for (Binding binding : callbackService.getBindings()) {
// first look for a callback binding whose name matches the
reference binding name
if (binding.getName().equals(refBinding.getName())) {
callbackBinding = binding;
break;
}
}
Not sure why this is checking that the callback binding name matches the
reference binding name before choosing a binding.Under what circumstances
will these names either match or not match.
There is also something similar going on in
CallbackReferenceImpl.selectCallbackWire()
// no exact match, so find callback binding with same name as
service binding
EndpointReference to = msgContext.getTo();
if (to == null) {
//FIXME: need better exception
throw new RuntimeException(Destination for forward call is not
available);
}
for (RuntimeWire wire : wires) {
if
(wire.getSource().getBinding().getName().equals(to.getBinding().getName()))
{
//FIXME: need better way to represent dynamic wire
if (wire.getTarget().getURI().equals(/)) { // dynamic wire
//FIXME: avoid doing this for genuine dynamic wires
return cloneAndBind(msgContext, wire);
}
//FIXME: no dynamic wire, so should attempt to create a
static wire
}
}
Again it's filtering bindings based on binding name but it's not clear what
the circumstances are where this match will be successful.
Regards
Simon
[1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg26380.html
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1935) Conversion of Bytes to/from String properties is not functioning correctly.
[ https://issues.apache.org/jira/browse/TUSCANY-1935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David T. Adcox updated TUSCANY-1935: Attachment: (was: Test1935.java) Conversion of Bytes to/from String properties is not functioning correctly. --- Key: TUSCANY-1935 URL: https://issues.apache.org/jira/browse/TUSCANY-1935 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-SDO-1.0 Environment: n/a Reporter: David T. Adcox Fix For: Java-SDO-Next Attachments: 1935.patch According to the SDO for Java specification v. 2.1.0, conversion of string properties to byte arrays and from byte array properties to string is a supported conversion type. This is confirmed on page 138 of the spec. Additionally, sections 8.1.4 and 8.1.5 describe the behavior of such conversions. When an attempt is made to perform one of the following functions, though, a ClassCastException is thrown: dataObj.getBytes(stringPropName); dataObj.set(stringPropName, byteArrayValue); dataObj.set(byteArrayPropName, stringValue); The dataObj.getString(byteArrayPropName) method seems to be functioning correctly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1935) Conversion of Bytes to/from String properties is not functioning correctly.
[ https://issues.apache.org/jira/browse/TUSCANY-1935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David T. Adcox updated TUSCANY-1935: Attachment: Test1935.java This test better shows the fixes, the previous test case only show the faults, it didn't function correctly, once the faults were fixed. Conversion of Bytes to/from String properties is not functioning correctly. --- Key: TUSCANY-1935 URL: https://issues.apache.org/jira/browse/TUSCANY-1935 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-SDO-1.0 Environment: n/a Reporter: David T. Adcox Fix For: Java-SDO-Next Attachments: 1935.patch, Test1935.java According to the SDO for Java specification v. 2.1.0, conversion of string properties to byte arrays and from byte array properties to string is a supported conversion type. This is confirmed on page 138 of the spec. Additionally, sections 8.1.4 and 8.1.5 describe the behavior of such conversions. When an attempt is made to perform one of the following functions, though, a ClassCastException is thrown: dataObj.getBytes(stringPropName); dataObj.set(stringPropName, byteArrayValue); dataObj.set(byteArrayPropName, stringValue); The dataObj.getString(byteArrayPropName) method seems to be functioning correctly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Binding names
On Dec 17, 2007 1:42 PM, Mike Edwards [EMAIL PROTECTED]
wrote:
Simon,
One comment inline.
Yours, Mike.
Simon Laws wrote:
Following on from the thread about identifying binding targets [1] the
SCA
assembly specification (lines 2319-2327) describes a binding name as
being
unique within a reference or service. If a binding name is not specified
in
the SCDL this is not the case currently. I.e the each binding adopts the
name of the reference or service to which it belongs. This makes
identification of an individual binding difficult, for example, if you
wanted to retrieve the details of an individual binding artifact from
the
live model. In the particular case where a default is chosen for a
binding
name (as opposed to a name having been specified) how about we do the
following:
References - Append the name of the target service to the end of the
reference name to form the binding name
Services - Append a number to the end of the binding name based on the
position of the binding name in the bindings list.
Why treat references differently to services? Why not use the idea of
appending a number in both cases? What about the case where the same
binding on a reference gets used for more than one target service?
There are a couple of places that use the binding name that could do
with a
little explanation if anyone knows the details.
CompositeActivator.addReferenceWire()
for (Binding binding : callbackService.getBindings()) {
// first look for a callback binding whose name matches
the
reference binding name
if (binding.getName().equals(refBinding.getName())) {
callbackBinding = binding;
break;
}
}
Not sure why this is checking that the callback binding name matches the
reference binding name before choosing a binding.Under what
circumstances
will these names either match or not match.
There is also something similar going on in
CallbackReferenceImpl.selectCallbackWire()
// no exact match, so find callback binding with same name as
service binding
EndpointReference to = msgContext.getTo();
if (to == null) {
//FIXME: need better exception
throw new RuntimeException(Destination for forward call is
not
available);
}
for (RuntimeWire wire : wires) {
if (wire.getSource().getBinding().getName().equals(
to.getBinding().getName()))
{
//FIXME: need better way to represent dynamic wire
if (wire.getTarget().getURI().equals(/)) { // dynamic
wire
//FIXME: avoid doing this for genuine dynamic wires
return cloneAndBind(msgContext, wire);
}
//FIXME: no dynamic wire, so should attempt to create a
static wire
}
}
Again it's filtering bindings based on binding name but it's not clear
what
the circumstances are where this match will be successful.
Regards
Simon
[1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg26380.html
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Hi Mike, as per the referenced thread, the Tuscany SCA runtime resolves
all of the bindings to targets so is slightly optimized when compared with
what you would see in the .composite file. So, for example, if you had the
component...
component name=SomeComponent
implementation.java class=my.ComponentImpl/
reference name=ref target=TargetService1 TargetService2
binding.ws/
binding.jsonrpc/
/reference
/component
Then you would end up with the following represented in the runtime currently
Component
Reference
Targets
TargetServiceA
TargetServiceB
Bindings
binding.ws
name - ref
binding.ws
name -= ref
If we append target service names it could be something like
Component
Reference
Targets
TargetServiceA
TargetServiceB
Bindings
binding.ws
name - ref#TargetServiceA
binding.ws
name -= ref#TargetServiceB
If we go with numbers
Component
Reference
Targets
TargetServiceA
TargetServiceB
Bindings
binding.ws
name - ref#1
binding.ws
name -= ref#2
Numbers would certainly work and give a nice symmetry with service but, as
is currently the case, you don't know what the reference is for. You might
get a hint from the URI but you might not.
Regards
Simon
Re: Build failure in calculator-implementation-policies sample
On Dec 17, 2007 12:14 PM, Simon Nash [EMAIL PROTECTED] wrote:
I am getting the following error when building the latest trunk. Any
ideas?
Simon
[INFO]
-
---
[INFO] Building Apache Tuscany SCA Calculator Sample using Implementation
Polici
es
[INFO]task-segment: [install]
[INFO]
-
---
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] Compiling 12 source files to
H:\tuscany58\sca\samples\calculator-implemen
tation-policies\target\classes
[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
[INFO] Compiling 1 source file to
H:\tuscany58\sca\samples\calculator-implementa
tion-policies\target\test-classes
[INFO] [surefire:test]
[INFO] Surefire report directory:
H:\tuscany58\sca\samples\calculator-implementa
tion-policies\target\surefire-reports
---
T E S T S
---
Running calculator.CalculatorTestCase
17-Dec-2007 11:28:27
org.apache.tuscany.sca.contribution.processor.ValidatingXML
StreamReader$1 error
WARNING: XMLSchema validation problem in:
file:/H:/tuscany58/sca/samples/calcula
tor-implementation-policies/target/classes/Calculator.composite, line: 28,
colum
n: 4
cvc-complex-type.2.4.a: Invalid content was found starting with element
'operati
on'. One of '{WC[##other:http://www.osoa.org/xmlns/sca/1.0]}' is
expected.
17-Dec-2007 11:28:28
INFO: Invoking operation - add
17-Dec-2007 11:28:28
FINER: Inovoking operation add with arguments 3.0, 2.0,
17-Dec-2007 11:28:28
INFO: Returned from operation - add
17-Dec-2007 11:28:28
FINER: Returning from operation add with return value 5
17-Dec-2007 11:28:28
INFO: Invoking operation - subtract
17-Dec-2007 11:28:28
FINER: Inovoking operation subtract with arguments 3.0, 2.0,
17-Dec-2007 11:28:28
INFO: Returned from operation - subtract
17-Dec-2007 11:28:28
FINER: Returning from operation subtract with return value 1
17-Dec-2007 11:28:28
org.apache.tuscany.sca.contribution.processor.ValidatingXML
StreamReader$1 error
WARNING: XMLSchema validation problem in:
file:/H:/tuscany58/sca/samples/calcula
tor-implementation-policies/target/classes/Calculator.composite, line: 28,
colum
n: 4
cvc-complex-type.2.4.a: Invalid content was found starting with element
'operati
on'. One of '{WC[##other:http://www.osoa.org/xmlns/sca/1.0]}' is
expected.
17-Dec-2007 11:28:28
INFO: Invoking operation - add
17-Dec-2007 11:28:28
FINER: Inovoking operation add with arguments 3.0, 2.0,
17-Dec-2007 11:28:28
INFO: Invoking operation - add
17-Dec-2007 11:28:28
FINER: Inovoking operation add with arguments 3.0, 2.0,
17-Dec-2007 11:28:28
INFO: Returned from operation - add
17-Dec-2007 11:28:28
FINER: Returning from operation add with return value 5
17-Dec-2007 11:28:28
INFO: Returned from operation - add
17-Dec-2007 11:28:28
FINER: Returning from operation add with return value 5
17-Dec-2007 11:28:28
INFO: Invoking operation - subtract
17-Dec-2007 11:28:28
FINER: Inovoking operation subtract with arguments 3.0, 2.0,
17-Dec-2007 11:28:28
INFO: Returned from operation - subtract
17-Dec-2007 11:28:28
FINER: Returning from operation subtract with return value 1
17-Dec-2007 11:28:28
INFO: Invoking operation - multiply
17-Dec-2007 11:28:28
FINER: Inovoking operation multiply with arguments 3.0, 2.0,
17-Dec-2007 11:28:28
INFO: Returned from operation - multiply
17-Dec-2007 11:28:28
FINER: Returning from operation multiply with return value
java.lang.RuntimeExce
ption: java.lang.SecurityException: Unable to locate a login configuration
Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 1.462 sec
FA
ILURE!
testCalculator(calculator.CalculatorTestCase) Time elapsed: 1.202 sec
ERRO
R!
java.lang.RuntimeException: java.lang.SecurityException: Unable to locate
a logi
n configuration
at
org.apache.tuscany.sca.policy.security.jaas.JaasAuthenticationPolicyH
andler.beforeInvoke(JaasAuthenticationPolicyHandler.java:58)
at
org.apache.tuscany.sca.implementation.java.invocation.PolicyHandlingI
nterceptor.applyPreInvocationPolicies(PolicyHandlingInterceptor.java:63)
at
org.apache.tuscany.sca.implementation.java.invocation.PolicyHandlingI
nterceptor.invoke(PolicyHandlingInterceptor.java:45)
at
org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JD
KInvocationHandler.java:249)
at
org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JD
KInvocationHandler.java:146)
at $Proxy7.multiply(Unknown Source)
at calculator.CalculatorServiceImpl.multiply(
CalculatorServiceImpl.java:
63)
at
Re: Binding names
On Dec 17, 2007 2:02 PM, Simon Laws [EMAIL PROTECTED] wrote:
On Dec 17, 2007 1:42 PM, Mike Edwards [EMAIL PROTECTED]
wrote:
Simon,
One comment inline.
Yours, Mike.
Simon Laws wrote:
Following on from the thread about identifying binding targets [1] the
SCA
assembly specification (lines 2319-2327) describes a binding name as
being
unique within a reference or service. If a binding name is not
specified in
the SCDL this is not the case currently. I.e the each binding adopts
the
name of the reference or service to which it belongs. This makes
identification of an individual binding difficult, for example, if you
wanted to retrieve the details of an individual binding artifact from
the
live model. In the particular case where a default is chosen for a
binding
name (as opposed to a name having been specified) how about we do the
following:
References - Append the name of the target service to the end of the
reference name to form the binding name
Services - Append a number to the end of the binding name based on the
position of the binding name in the bindings list.
Why treat references differently to services? Why not use the idea of
appending a number in both cases? What about the case where the same
binding on a reference gets used for more than one target service?
There are a couple of places that use the binding name that could do
with a
little explanation if anyone knows the details.
CompositeActivator.addReferenceWire()
for (Binding binding : callbackService.getBindings()) {
// first look for a callback binding whose name
matches the
reference binding name
if (binding.getName().equals(refBinding.getName())) {
callbackBinding = binding;
break;
}
}
Not sure why this is checking that the callback binding name matches
the
reference binding name before choosing a binding.Under what
circumstances
will these names either match or not match.
There is also something similar going on in
CallbackReferenceImpl.selectCallbackWire()
// no exact match, so find callback binding with same name as
service binding
EndpointReference to = msgContext.getTo();
if (to == null) {
//FIXME: need better exception
throw new RuntimeException(Destination for forward call
is not
available);
}
for (RuntimeWire wire : wires) {
if (wire.getSource().getBinding().getName().equals(
to.getBinding().getName()))
{
//FIXME: need better way to represent dynamic wire
if (wire.getTarget().getURI().equals(/)) { //
dynamic wire
//FIXME: avoid doing this for genuine dynamic
wires
return cloneAndBind(msgContext, wire);
}
//FIXME: no dynamic wire, so should attempt to create
a
static wire
}
}
Again it's filtering bindings based on binding name but it's not clear
what
the circumstances are where this match will be successful.
Regards
Simon
[1]
http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg26380.html
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Hi Mike, as per the referenced thread, the Tuscany SCA runtime resolves
all of the bindings to targets so is slightly optimized when compared with
what you would see in the .composite file. So, for example, if you had the
component...
component name=SomeComponent
implementation.java class=my.ComponentImpl/
reference name=ref target=TargetService1 TargetService2
binding.ws/
binding.jsonrpc/
/reference
/component
Then you would end up with the following represented in the runtime currently
Component
Reference
Targets
TargetServiceA
TargetServiceB
Bindings
binding.ws
name - ref
binding.ws
name -= ref
If we append target service names it could be something like
Component
Reference
Targets
TargetServiceA
TargetServiceB
Bindings
binding.ws
name - ref#TargetServiceA
binding.ws
name -= ref#TargetServiceB
If we go with numbers
Component
Reference
Targets
TargetServiceA
TargetServiceB
Bindings
binding.ws
name - ref#1
binding.ws
name -= ref#2
Numbers would certainly work and give a nice
Account Request - Mark Combellack - Tuscany (incubating)
Dear root, Please create an id for Mark Combellack on the Tuscany project under Incubation. Preferred userid:mcombellack Full name: Mark Combellack Forwarding email address:[EMAIL PROTECTED] Requested Karma for: ws-tuscany ICLA is on file. Votes: tuscany-private, Oct 29, Message-ID: [EMAIL PROTECTED] incubator-private, Nov 1, Message-ID: [EMAIL PROTECTED] Many thanks, ...ant
[jira] Created: (TUSCANY-1937) Duplicate binding name not flagged as error
Duplicate binding name not flagged as error --- Key: TUSCANY-1937 URL: https://issues.apache.org/jira/browse/TUSCANY-1937 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-1.0.1 Reporter: Simon Nash Fix For: Java-SCA-Next If multiple bindings on a service or reference have the same name (explicit or defaulted), Tuscany should raise an error because this is illegal according to the SCA Assembly specification. Both of the following modifications of myapp.scdl in samples/callback-ws-client should be illegal, but currently they are both accepted: - - - - - - - - example 1 - - - - - - - - composite xmlns=http://www.osoa.org/xmlns/sca/1.0; targetNamespace=http://myapp; name=myapp component name=MyClientComponent implementation.java class=myapp.MyClientImpl / reference name=myService interface.java interface=myserver.MyService callbackInterface=myserver.MyServiceCallback / binding.ws name=fred uri=http://localhost:8086/MyServiceComponent; / binding.sca name=fred / callback binding.ws / /callback /reference /component /composite - - - - - - - - example 2 - - - - - - - - composite xmlns=http://www.osoa.org/xmlns/sca/1.0; targetNamespace=http://myapp; name=myapp component name=MyClientComponent implementation.java class=myapp.MyClientImpl / reference name=myService interface.java interface=myserver.MyService callbackInterface=myserver.MyServiceCallback / binding.ws uri=http://localhost:8086/MyServiceComponent; / binding.sca / callback binding.ws / /callback /reference /component /composite -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [NOTICE] Mark Combellack voted as Tuscany committer
Your CLA is on file now so i've sent off the userid request. That may take a few days to get actioned and then you'll be emailed your userid and password. Once you receive that if you've nothing ready to commit you could test SVN access by something like creating yourself a sandbox directory with: svn mkdir https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/mcombellack See the Apache guide for new committers and the committer FAQ for info about being an Apache committer: http://www.apache.org/dev/new-committers-guide.html http://www.apache.org/dev/committers.html ...ant On Nov 1, 2007 7:40 PM, Mark Combellack [EMAIL PROTECTED] wrote: kelvin goodson [EMAIL PROTECTED] writes: Welcome Mark! -- Kelvin On 01/11/2007, ant elder [EMAIL PROTECTED] wrote: The Tuscany PPMC and Incubator PMC have voted for Mark Combellack to become a Tuscany committer. Congratulations and welcome Mark! ...ant Thank you all for your kind welcome. I am looking forward to my first Tuscany commit and working with you all. Mark Now that the CLA is on file I've sent
[jira] Commented: (TUSCANY-1937) Duplicate binding name not flagged as error
[ https://issues.apache.org/jira/browse/TUSCANY-1937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12552466 ] Simon Laws commented on TUSCANY-1937: - For example 2 a discussion is started [1] about how to generate default binding names. [1] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg26471.html Duplicate binding name not flagged as error --- Key: TUSCANY-1937 URL: https://issues.apache.org/jira/browse/TUSCANY-1937 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-1.0.1 Reporter: Simon Nash Fix For: Java-SCA-Next If multiple bindings on a service or reference have the same name (explicit or defaulted), Tuscany should raise an error because this is illegal according to the SCA Assembly specification. Both of the following modifications of myapp.scdl in samples/callback-ws-client should be illegal, but currently they are both accepted: - - - - - - - - example 1 - - - - - - - - composite xmlns=http://www.osoa.org/xmlns/sca/1.0; targetNamespace=http://myapp; name=myapp component name=MyClientComponent implementation.java class=myapp.MyClientImpl / reference name=myService interface.java interface=myserver.MyService callbackInterface=myserver.MyServiceCallback / binding.ws name=fred uri=http://localhost:8086/MyServiceComponent; / binding.sca name=fred / callback binding.ws / /callback /reference /component /composite - - - - - - - - example 2 - - - - - - - - composite xmlns=http://www.osoa.org/xmlns/sca/1.0; targetNamespace=http://myapp; name=myapp component name=MyClientComponent implementation.java class=myapp.MyClientImpl / reference name=myService interface.java interface=myserver.MyService callbackInterface=myserver.MyServiceCallback / binding.ws uri=http://localhost:8086/MyServiceComponent; / binding.sca / callback binding.ws / /callback /reference /component /composite -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Binding names
See comments inline.
Simon
Simon Laws wrote:
On Dec 17, 2007 1:42 PM, Mike Edwards [EMAIL PROTECTED]
wrote:
Simon,
One comment inline.
Yours, Mike.
Simon Laws wrote:
Following on from the thread about identifying binding targets [1] the
SCA
assembly specification (lines 2319-2327) describes a binding name as
being
unique within a reference or service. If a binding name is not specified
in
the SCDL this is not the case currently. I.e the each binding adopts the
name of the reference or service to which it belongs.
For bindings specified in SCDL, this is correct. From section 1.7 in
the Assembly spec:
2319 name (optional) – a name for the binding instance (a QName). The name
attribute
2320 allows distinction between multiple binding elements on a single service
or reference. The
2321 default value of the name attribute is the service or reference name. When
a service or
2322 reference has multiple bindings, only one can have the default value; all
others must have
2323 a value specified that is unique within the service or reference. The name
also permits the
2324 binding instance to be referenced from elsewhere – particularly useful for
some types of
2325 binding, which can be declared in a definitions document as a template and
referenced
2326 from other binding instances, simplifying the definition of more complex
binding instances
2327 (see the JMS Binding specification [11] for examples of this referencing).
So having more than one anonymous binding on a single service or
reference is not allowed and should be flagged as an error. I have
opened TUSCANY-1937 for this.
For resolved bindings that are generated by the Tuscany runtime in
the case of multiple reference targets for the same binding, there are
some cases where the generated binding names won't be unique unless a
name mangling convention is used, as discussed below.
IMO, the need to create mangled names for resolved bindings is a
further reason why resolved bindings should be held elsewhere in the
model than the bindings specified in SCDL.
There's no need to do name mangling on the service side. Multiple
anonymous bindings for a service are illegal.
This makes
identification of an individual binding difficult, for example, if you
wanted to retrieve the details of an individual binding artifact from
the
live model. In the particular case where a default is chosen for a
binding
name (as opposed to a name having been specified) how about we do the
following:
References - Append the name of the target service to the end of the
reference name to form the binding name
Services - Append a number to the end of the binding name based on the
position of the binding name in the bindings list.
Why treat references differently to services? Why not use the idea of
appending a number in both cases? What about the case where the same
binding on a reference gets used for more than one target service?
There are a couple of places that use the binding name that could do
with a
little explanation if anyone knows the details.
CompositeActivator.addReferenceWire()
for (Binding binding : callbackService.getBindings()) {
// first look for a callback binding whose name matches
the
reference binding name
if (binding.getName().equals(refBinding.getName())) {
callbackBinding = binding;
break;
}
}
Not sure why this is checking that the callback binding name matches the
reference binding name before choosing a binding.Under what
circumstances
will these names either match or not match.
This code has been commented out. Its intention was to allow the
SCDL author to control the selection for a callback binding based
on the forward binding being used. If there is a name match, this
is given the highest priority in the selection algorithm.
There is also something similar going on in
CallbackReferenceImpl.selectCallbackWire()
// no exact match, so find callback binding with same name as
service binding
EndpointReference to = msgContext.getTo();
if (to == null) {
//FIXME: need better exception
throw new RuntimeException(Destination for forward call is
not
available);
}
for (RuntimeWire wire : wires) {
if (wire.getSource().getBinding().getName().equals(
to.getBinding().getName()))
{
//FIXME: need better way to represent dynamic wire
if (wire.getTarget().getURI().equals(/)) { // dynamic
wire
//FIXME: avoid doing this for genuine dynamic wires
return cloneAndBind(msgContext, wire);
}
//FIXME: no dynamic wire, so should attempt to create a
static wire
}
}
Again it's filtering bindings based on binding name but it's not clear
what
the
Re: Binding names
Hi
Some questions inline
Simon
On Dec 17, 2007 4:54 PM, Simon Nash [EMAIL PROTECTED] wrote:
See comments inline.
Simon
Simon Laws wrote:
On Dec 17, 2007 1:42 PM, Mike Edwards [EMAIL PROTECTED]
wrote:
Simon,
One comment inline.
Yours, Mike.
Simon Laws wrote:
Following on from the thread about identifying binding targets [1] the
SCA
assembly specification (lines 2319-2327) describes a binding name as
being
unique within a reference or service. If a binding name is not
specified
in
the SCDL this is not the case currently. I.e the each binding adopts
the
name of the reference or service to which it belongs.
For bindings specified in SCDL, this is correct. From section 1.7 in
the Assembly spec:
2319 name (optional) – a name for the binding instance (a QName). The name
attribute
2320 allows distinction between multiple binding elements on a single
service or reference. The
2321 default value of the name attribute is the service or reference name.
When a service or
2322 reference has multiple bindings, only one can have the default value;
all others must have
2323 a value specified that is unique within the service or reference. The
name also permits the
2324 binding instance to be referenced from elsewhere – particularly
useful for some types of
2325 binding, which can be declared in a definitions document as a
template and referenced
2326 from other binding instances, simplifying the definition of more
complex binding instances
2327 (see the JMS Binding specification [11] for examples of this
referencing).
So having more than one anonymous binding on a single service or
reference is not allowed and should be flagged as an error. I have
opened TUSCANY-1937 for this.
For resolved bindings that are generated by the Tuscany runtime in
the case of multiple reference targets for the same binding, there are
some cases where the generated binding names won't be unique unless a
name mangling convention is used, as discussed below.
IMO, the need to create mangled names for resolved bindings is a
further reason why resolved bindings should be held elsewhere in the
model than the bindings specified in SCDL.
I agree but others didn't seem to like the idea of keeping both the original
bindings and the resolved bindings.
There's no need to do name mangling on the service side. Multiple
anonymous bindings for a service are illegal.
So there is an element of interpretation of lines 2322-2323 here which is
where we differ.
2322 reference has multiple bindings, only one can have the default value;
all others must have
2323 a value specified that is unique within the service or reference. The
name also permits the
I interpreted must have a value specified to mean that the binding must
end up with a unique value while from reading your response you have
interpreted is as must have a value specified BY THE USER. On reflection
you are probably right and it certainly makes more sense in the case of
identifying binding artifacts once they have been contributed. Although if a
user were to ask for some information for a binding given a name they
provided originally they may get information for more than one resolved
binding as per the discussion below.
This makes
identification of an individual binding difficult, for example, if you
wanted to retrieve the details of an individual binding artifact from
the
live model. In the particular case where a default is chosen for a
binding
name (as opposed to a name having been specified) how about we do the
following:
References - Append the name of the target service to the end of the
reference name to form the binding name
Services - Append a number to the end of the binding name based on the
position of the binding name in the bindings list.
Why treat references differently to services? Why not use the idea of
appending a number in both cases? What about the case where the same
binding on a reference gets used for more than one target service?
There are a couple of places that use the binding name that could do
with a
little explanation if anyone knows the details.
CompositeActivator.addReferenceWire()
for (Binding binding : callbackService.getBindings()) {
// first look for a callback binding whose name matches
the
reference binding name
if (binding.getName().equals(refBinding.getName())) {
callbackBinding = binding;
break;
}
}
Not sure why this is checking that the callback binding name matches
the
reference binding name before choosing a binding.Under what
circumstances
will these names either match or not match.
This code has been commented out. Its intention was to allow the
SCDL author to control the selection for a callback binding based
on
[jira] Created: (TUSCANY-1938) doc-lit-wrapped WSDLs with wrapper elems with non-substitution-group refs are incorrectly treated as non-wrapped
doc-lit-wrapped WSDLs with wrapper elems with non-substitution-group refs are incorrectly treated as non-wrapped Key: TUSCANY-1938 URL: https://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 style which qualifies for mapping to wrapped Java: ... (v) The wrapper elements only contain child elements, they must not contain other structures such as wildcards (element or attribute), xsd:choice, substitution groups (element references are not permitted) or attributes; furthermore, they must not be nillable. I think the Tuscany interpretation of this statement is wrong in treating certain WSDLs as non-wrapped rather than wrapped. This makes it hard to, say, consistently choose to work in the doc-lit-wrapped WSDL style with a pre-existing WSDL file. I'll attach a WSDL file for reference, but let me show an excerpt. This is not treated as wrapped by Tuscany: element name=person type=tns:Person/ complexType name=Person sequence element name=firstName type=xsd:string/ element name=lastName type=xsd:string/ /sequence /complexType element name=getGreetings complexType sequence element name=greeting type=xsd:string/ element ref=tns:person/ /sequence /complexType /element IMO, the JAX-WS RI toolset, (wsimport) has the best interpretation of the JAX-WS spec.The 'wsimport' tool will treat this as wrapped, (i.e. gen the Java with @RequestWrapper), which I think is correct. (BTW, a service impl that I wrote from this WSDL worked fine on an IBM WAS 6.1 runtime with JAX-WS support.) In the sample WSDL attached, I show what I think the JAX-WS spec is trying to disallow. The key point I think is that they're trying to disallow use of substitution groups. So, if 'person' above had been an abstract element with an associated substitution group, then JAX-WS RI would map this in a non--wrapped style. This also fits with the fact that the statement (element references are not permitted) is not made in a separate sub-bullet, but only in parentheses directly next to substitution groups. Though I still can't explain exactly why the authors phrased it the way they did ! As further proof this is confusing, here's another JIRA on the exact same subject on the CXF project (which apparently hasn't been resolved). https://issues.apache.org/jira/browse/CXF-1079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12531198 Within the Tuscany runtime, I believe this function is implemented in the WSDLOperationIntrospectorImpl$Wrapper.getChildElements() method. There may or may not be a Tuscany tools hit here as well. I haven't checked. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1938) doc-lit-wrapped WSDLs with wrapper elems with non-substitution-group refs are incorrectly treated as non-wrapped
[ 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-group refs are incorrectly treated as non-wrapped Key: TUSCANY-1938 URL: https://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 Attachments: helloworld.wsdl The JAX-WS Spec, Sec. 2.3.1.2, makes the following confusing statement in defining the WSDL style which qualifies for mapping to wrapped Java: ... (v) The wrapper elements only contain child elements, they must not contain other structures such as wildcards (element or attribute), xsd:choice, substitution groups (element references are not permitted) or attributes; furthermore, they must not be nillable. I think the Tuscany interpretation of this statement is wrong in treating certain WSDLs as non-wrapped rather than wrapped. This makes it hard to, say, consistently choose to work in the doc-lit-wrapped WSDL style with a pre-existing WSDL file. I'll attach a WSDL file for reference, but let me show an excerpt. This is not treated as wrapped by Tuscany: element name=person type=tns:Person/ complexType name=Person sequence element name=firstName type=xsd:string/ element name=lastName type=xsd:string/ /sequence /complexType element name=getGreetings complexType sequence element name=greeting type=xsd:string/ element ref=tns:person/ /sequence /complexType /element IMO, the JAX-WS RI toolset, (wsimport) has the best interpretation of the JAX-WS spec.The 'wsimport' tool will treat this as wrapped, (i.e. gen the Java with @RequestWrapper), which I think is correct. (BTW, a service impl that I wrote from this WSDL worked fine on an IBM WAS 6.1 runtime with JAX-WS support.) In the sample WSDL attached, I show what I think the JAX-WS spec is trying to disallow. The key point I think is that they're trying to disallow use of substitution groups. So, if 'person' above had been an abstract element with an associated substitution group, then JAX-WS RI would map this in a non--wrapped style. This also fits with the fact that the statement (element references are not permitted) is not made in a separate sub-bullet, but only in parentheses directly next to substitution groups. Though I still can't explain exactly why the authors phrased it the way they did ! As further proof this is confusing, here's another JIRA on the exact same subject on the CXF project (which apparently hasn't been resolved). https://issues.apache.org/jira/browse/CXF-1079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12531198 Within the Tuscany runtime, I believe this function is implemented in the WSDLOperationIntrospectorImpl$Wrapper.getChildElements() method. There may or may not be a Tuscany tools hit here as well. I haven't checked. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Integrating BPEL in the The Store scenario
I have been thinking on ways to get BPEL more integrated in our sample scenarios, particularly in our store scenario. I'd like to have the ShoppingCart defined as a BPEL component, that would exercise some more advanced BPEL features such as correlation, and state persistence. I'm going to start playing on this area, and define some new modules for this work based on this previous discussion [1]. Thoughts ? [1] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg26418.html -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Binding target information
Jean-Sebastien Delfino wrote: Mike Edwards wrote: Folks, A thought here is whether we should be keeping around all of the original SCDL at all times. I can regard the Domain as consisting of the SCDL made up from all the contributions made into it. I have the view that the Domain is a kind of distributed database of configuration information. I think this is separate from the runtime information within Tuscany which is an implementation of the design laid down in the Domain configuration. So perhaps the idea should be to always keep the Domain information (XML form if desired) and to reference it from the runtime entities. That way, it will be always possible to go back and retrieve the original Domain configuration information. Thoughts? Yours, Mike. +1 to all that The runtime uses a compiled optimized model different from how the model was expressed in the original XML. I think we need to keep the original form (as you said XML if desired) in the domain, when new XML is added go back to the XML and re-compile it, then hand the new compiled form to the runtime. Twisting the compiled model to keep some of the original XML and patch it when new XML is added will be too complicated and won't work. I don't think it's twisting the compiled model to retain the original information, especially when it's not possible to recover this from the compiled model. For debugging and error reporting, it's useful for the runtime to know about the original SCDL so that error reporting can be done in terms of what the user sees and not (for example) by exposing runtime-generated binding names that aren't the ones the user provided, and in the worst case might even collide with user-specified names. The overhead of retaining this information (at least in the case being discussed) is small. Patching the runtime model to update it with new XML is a different discussion that introduces more complex issues than simply retaining the user's view of the configuration for diagnostic purposes. Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Binding names
Comments inline.
Simon
Simon Laws wrote:
Hi
Some questions inline
Simon
On Dec 17, 2007 4:54 PM, Simon Nash [EMAIL PROTECTED] wrote:
See comments inline.
Simon
Simon Laws wrote:
On Dec 17, 2007 1:42 PM, Mike Edwards [EMAIL PROTECTED]
wrote:
Simon,
One comment inline.
Yours, Mike.
Simon Laws wrote:
Following on from the thread about identifying binding targets [1] the
SCA
assembly specification (lines 2319-2327) describes a binding name as
being
unique within a reference or service. If a binding name is not
specified
in
the SCDL this is not the case currently. I.e the each binding adopts
the
name of the reference or service to which it belongs.
For bindings specified in SCDL, this is correct. From section 1.7 in
the Assembly spec:
2319 name (optional) – a name for the binding instance (a QName). The name
attribute
2320 allows distinction between multiple binding elements on a single
service or reference. The
2321 default value of the name attribute is the service or reference name.
When a service or
2322 reference has multiple bindings, only one can have the default value;
all others must have
2323 a value specified that is unique within the service or reference. The
name also permits the
2324 binding instance to be referenced from elsewhere – particularly
useful for some types of
2325 binding, which can be declared in a definitions document as a
template and referenced
2326 from other binding instances, simplifying the definition of more
complex binding instances
2327 (see the JMS Binding specification [11] for examples of this
referencing).
So having more than one anonymous binding on a single service or
reference is not allowed and should be flagged as an error. I have
opened TUSCANY-1937 for this.
For resolved bindings that are generated by the Tuscany runtime in
the case of multiple reference targets for the same binding, there are
some cases where the generated binding names won't be unique unless a
name mangling convention is used, as discussed below.
IMO, the need to create mangled names for resolved bindings is a
further reason why resolved bindings should be held elsewhere in the
model than the bindings specified in SCDL.
I agree but others didn't seem to like the idea of keeping both the original
bindings and the resolved bindings.
I saw a post from Sebastien saying this, to which I have just responded.
I also saw posts from others who did think the original information
should be available. As we explore this further, I think we are seeing
more reasons (like error reporting) for why it's desirable to retain the
original information.
There's no need to do name mangling on the service side. Multiple
anonymous bindings for a service are illegal.
So there is an element of interpretation of lines 2322-2323 here which is
where we differ.
2322 reference has multiple bindings, only one can have the default value;
all others must have
2323 a value specified that is unique within the service or reference. The
name also permits the
I interpreted must have a value specified to mean that the binding must
end up with a unique value while from reading your response you have
interpreted is as must have a value specified BY THE USER. On reflection
you are probably right and it certainly makes more sense in the case of
identifying binding artifacts once they have been contributed. Although if a
user were to ask for some information for a binding given a name they
provided originally they may get information for more than one resolved
binding as per the discussion below.
When I see the word specified, I interpret this as meaning specified
by the user unless there's some indication that a different meaning
should apply. In this case, I believe it's referring to a name specified
using the name attribute of the binding element.
This makes
identification of an individual binding difficult, for example, if you
wanted to retrieve the details of an individual binding artifact from
the
live model. In the particular case where a default is chosen for a
binding
name (as opposed to a name having been specified) how about we do the
following:
References - Append the name of the target service to the end of the
reference name to form the binding name
Services - Append a number to the end of the binding name based on the
position of the binding name in the bindings list.
Why treat references differently to services? Why not use the idea of
appending a number in both cases? What about the case where the same
binding on a reference gets used for more than one target service?
There are a couple of places that use the binding name that could do
with a
little explanation if anyone knows the details.
CompositeActivator.addReferenceWire()
for (Binding binding : callbackService.getBindings()) {
// first look for a callback binding whose name
Re: Integrating BPEL in the The Store scenario
On Dec 17, 2007 7:55 PM, Luciano Resende [EMAIL PROTECTED] wrote: I have been thinking on ways to get BPEL more integrated in our sample scenarios, particularly in our store scenario. I'd like to have the ShoppingCart defined as a BPEL component, that would exercise some more advanced BPEL features such as correlation, and state persistence. I'm going to start playing on this area, and define some new modules for this work based on this previous discussion [1]. Thoughts ? [1] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg26418.html -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://people.apache.org/%7Elresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Hi Luciano Sounds interesting. Maybe we could also do something realistic with order processing so that we can show something of the flow that happens once the order has been entered. Be a good excuse to include some orchestration with external services and of services running in various hosting environments. Regards Simon
JAXB databinding causing build failure in itest/exceptions-simple-ws
I'm seeing the failure below when attempting to build itest/exceptions-simple-ws from the latest trunk. From the message and stack trace, it looks like the Exception2Exception transformer that was previously using a POJO-JavaBean serializer has been changed to use a JAXB serializer, and this is throwing a JAXB exception because the business exception object contains an object whose class doesn't have a no-arg constructor (java.lang.StackTraceElement). Does anyone know what has changed here and the reason why? Simon Here's the error: --- T E S T S --- Running com.example.ExampleTestCase 17-Dec-2007 21:40:27 org.apache.catalina.core.StandardEngine start INFO: Starting Servlet Engine: Apache Tomcat/6.0.10 17-Dec-2007 21:40:27 org.apache.catalina.startup.ContextConfig defaultWebConfig INFO: No default web.xml 17-Dec-2007 21:40:27 org.apache.catalina.startup.DigesterFactory register WARNING: Could not get url for /javax/servlet/jsp/resources/jsp_2_0.xsd 17-Dec-2007 21:40:27 org.apache.catalina.startup.DigesterFactory register WARNING: Could not get url for /javax/servlet/jsp/resources/web-jsptaglibrary_1_ 1.dtd 17-Dec-2007 21:40:27 org.apache.catalina.startup.DigesterFactory register WARNING: Could not get url for /javax/servlet/jsp/resources/web-jsptaglibrary_1_ 2.dtd 17-Dec-2007 21:40:27 org.apache.catalina.startup.DigesterFactory register WARNING: Could not get url for /javax/servlet/jsp/resources/web-jsptaglibrary_2_ 0.xsd 17-Dec-2007 21:40:27 org.apache.catalina.startup.DigesterFactory register WARNING: Could not get url for /javax/servlet/resources/j2ee_web_services_1_1.xs d 17-Dec-2007 21:40:27 org.apache.coyote.http11.Http11Protocol init INFO: Initializing Coyote HTTP/1.1 on http-8085 17-Dec-2007 21:40:27 org.apache.coyote.http11.Http11Protocol start INFO: Starting Coyote HTTP/1.1 on http-8085 17-Dec-2007 21:40:27 org.apache.tuscany.sca.http.tomcat.TomcatServer addServletM apping INFO: Added Servlet mapping: http://EUREKA:8085/axis2/services/ExampleService 17-Dec-2007 21:40:28 org.apache.tuscany.sca.binding.ws.axis2.Axis2ServiceInOutSy ncMessageReceiver invokeBusinessLogic SEVERE: org.apache.tuscany.sca.databinding.TransformationException: com.sun.xml. bind.v2.runtime.IllegalAnnotationsException: 1 counts of IllegalAnnotationExcept ions java.lang.StackTraceElement does not have a no-arg default constructor. this problem is related to the following location: at java.lang.StackTraceElement at public java.lang.StackTraceElement[] java.lang.Throwable.getS tackTrace() at java.lang.Throwable at java.lang.Exception at com.example.BusinessException org.osoa.sca.ServiceRuntimeException: org.apache.tuscany.sca.databinding.Transfo rmationException: com.sun.xml.bind.v2.runtime.IllegalAnnotationsException: 1 cou nts of IllegalAnnotationExceptions java.lang.StackTraceElement does not have a no-arg default constructor. this problem is related to the following location: at java.lang.StackTraceElement at public java.lang.StackTraceElement[] java.lang.Throwable.getS tackTrace() at java.lang.Throwable at java.lang.Exception at com.example.BusinessException at org.apache.tuscany.sca.core.invocation.RuntimeWireInvoker.invoke(Runt imeWireInvoker.java:127) at org.apache.tuscany.sca.core.invocation.RuntimeWireInvoker.invoke(Runt imeWireInvoker.java:89) at org.apache.tuscany.sca.core.invocation.RuntimeWireInvoker.invoke(Runt imeWireInvoker.java:83) at org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.invoke(RuntimeWi reImpl.java:127) at org.apache.tuscany.sca.binding.ws.axis2.Axis2ServiceProvider.invokeTa rget(Axis2ServiceProvider.java:572) at org.apache.tuscany.sca.binding.ws.axis2.Axis2ServiceInOutSyncMessageR eceiver.invokeBusinessLogic(Axis2ServiceInOutSyncMessageReceiver.java:59) at org.apache.axis2.receivers.AbstractInOutSyncMessageReceiver.invokeBus inessLogic(AbstractInOutSyncMessageReceiver.java:42) at org.apache.axis2.receivers.AbstractMessageReceiver.receive(AbstractMe ssageReceiver.java:96) at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:145) at org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostReq uest(HTTPTransportUtils.java:275) at org.apache.axis2.transport.http.AxisServlet.doPost(AxisServlet.java:1 20) at javax.servlet.http.HttpServlet.service(HttpServlet.java:727) at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl icationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF ilterChain.java:206) at
@promote documentation
body { margin: 0 0 0 0; padding:0 0 0 0 } td,div {
font-family:Tahoma;font-size:8pt;vertical-align:top } body { margin: 0 0 0 0;
padding:0 0 0 0 } .transcript { background-color:#d2d2d2; } .messageBlock {
margin-left:4px; margin-bottom:3px } .message { margin-left:100px;
word-wrap:break-word; white-space:-moz-pre-wrap; _white-space:pre; }
.messageCont { margin-left:100px; word-wrap:break-word;
white-space:-moz-pre-wrap; _white-space:pre;} .other {
color:#39577a;vertical-align:top;font-weight:bold;font-style:normal;float:left;
width:95px; } .myself {
color:#da8103;font-style:normal;font-weight:bold;font-style:normal;float:left;
width:95px; } .otherCont { font-size:8px;text-align:right;
color:#39577a;font-family:Arial,Lucida
Grande;font-style:normal;vertical-align:top;font-weight:bold;float:left;
width:95px; } .myselfCont { font-size:8px;text-align:right;
color:#da8103;font-family:Arial,Lucida
Grande;font-style:normal;vertical-align:top;font-weight:bold;float:left;
width:95px; } .system { margin-left:4px;
word-wrap:break-word;color:#da8103;font-style:normal;font-weight:normal;
white-space:-moz-pre-wrap; _white-space:pre; } .showTimestamp {
margin-right:3px; float:right;
color:#99;font-style:normal;font-weight:normal; } .other1 {
color:#ac2000;vertical-align:top;font-weight:bold;font-style:normal;float:left;
width:95px; } .otherCont1 { font-size:8px;text-align:right;
color:#ac2000;font-family:Arial,Lucida
Grande;font-style:normal;vertical-align:top;font-weight:bold;float:left;
width:95px; } .other2 {
color:#3c9fa8;vertical-align:top;font-weight:bold;font-style:normal;float:left;
width:95px; } .otherCont2 { font-size:8px;text-align:right;
color:#3c9fa8;font-family:Arial,Lucida
Grande;font-style:normal;vertical-align:top;font-weight:bold;float:left;
width:95px; } .other3 {
color:#e25614;vertical-align:top;font-weight:bold;font-style:normal;float:left;
width:95px; } .otherCont3 { font-size:8px;text-align:right;
color:#e25614;font-family:Arial,Lucida
Grande;font-style:normal;vertical-align:top;font-weight:bold;float:left;
width:95px; } .other4 {
color:#0b6ac8;vertical-align:top;font-weight:bold;font-style:normal;float:left;
width:95px; } .otherCont4 { font-size:8px;text-align:right;
color:#0b6ac8;font-family:Arial,Lucida
Grande;font-style:normal;vertical-align:top;font-weight:bold;float:left;
width:95px; } .other5 {
color:#b23290;vertical-align:top;font-weight:bold;font-style:normal;float:left;
width:95px; } .otherCont5 { font-size:8px;text-align:right;
color:#b23290;font-family:Arial,Lucida
Grande;font-style:normal;vertical-align:top;font-weight:bold;float:left;
width:95px; } .other6 {
color:#02e7c7;vertical-align:top;font-weight:bold;font-style:normal;float:left;
width:95px; } .otherCont6 { font-size:8px;text-align:right;
color:#02e7c7;font-family:Arial,Lucida
Grande;font-style:normal;vertical-align:top;font-weight:bold;float:left;
width:95px; } .other7 {
color:#5b3284;vertical-align:top;font-weight:bold;font-style:normal;float:left;
width:95px; } .otherCont7 { font-size:8px;text-align:right;
color:#5b3284;font-family:Arial,Lucida
Grande;font-style:normal;vertical-align:top;font-weight:bold;float:left;
width:95px; } .tsDisplay { display:block } I was looking for the
documentation of @promote of the element reference. I could not find it in the
specs...
Can someone help me with this?
Thanks
Mahi
You must be the change you wish to see in the world -- Mahatma Gandhi.
-
Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.
Re: JAXB databinding causing build failure in itest/exceptions-simple-ws
Hi, I just tried and it apparently works with IBM JDK and SUN JDK is not happy with it. But anyway, we now use the JAXB to serialize POJO into XML and vice versa. The POJOs have to follow JavaBean patterns as I described in the e-mail when I checked in the changes. Now the question is how do we serialize the pure java exceptions (not generated from JAX-WS) into XML so that they can flow over SOAP. Maybe we have to create a speical databinding from exceptions and then have special transformers to deal with the Exception/XML transformations. Thanks, Raymond - Original Message - From: Simon Nash [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Monday, December 17, 2007 2:24 PM Subject: JAXB databinding causing build failure in itest/exceptions-simple-ws I'm seeing the failure below when attempting to build itest/exceptions-simple-ws from the latest trunk. From the message and stack trace, it looks like the Exception2Exception transformer that was previously using a POJO-JavaBean serializer has been changed to use a JAXB serializer, and this is throwing a JAXB exception because the business exception object contains an object whose class doesn't have a no-arg constructor (java.lang.StackTraceElement). Does anyone know what has changed here and the reason why? Simon Here's the error: --- T E S T S --- Running com.example.ExampleTestCase 17-Dec-2007 21:40:27 org.apache.catalina.core.StandardEngine start INFO: Starting Servlet Engine: Apache Tomcat/6.0.10 17-Dec-2007 21:40:27 org.apache.catalina.startup.ContextConfig defaultWebConfig INFO: No default web.xml 17-Dec-2007 21:40:27 org.apache.catalina.startup.DigesterFactory register WARNING: Could not get url for /javax/servlet/jsp/resources/jsp_2_0.xsd 17-Dec-2007 21:40:27 org.apache.catalina.startup.DigesterFactory register WARNING: Could not get url for /javax/servlet/jsp/resources/web-jsptaglibrary_1_ 1.dtd 17-Dec-2007 21:40:27 org.apache.catalina.startup.DigesterFactory register WARNING: Could not get url for /javax/servlet/jsp/resources/web-jsptaglibrary_1_ 2.dtd 17-Dec-2007 21:40:27 org.apache.catalina.startup.DigesterFactory register WARNING: Could not get url for /javax/servlet/jsp/resources/web-jsptaglibrary_2_ 0.xsd 17-Dec-2007 21:40:27 org.apache.catalina.startup.DigesterFactory register WARNING: Could not get url for /javax/servlet/resources/j2ee_web_services_1_1.xs d 17-Dec-2007 21:40:27 org.apache.coyote.http11.Http11Protocol init INFO: Initializing Coyote HTTP/1.1 on http-8085 17-Dec-2007 21:40:27 org.apache.coyote.http11.Http11Protocol start INFO: Starting Coyote HTTP/1.1 on http-8085 17-Dec-2007 21:40:27 org.apache.tuscany.sca.http.tomcat.TomcatServer addServletM apping INFO: Added Servlet mapping: http://EUREKA:8085/axis2/services/ExampleService 17-Dec-2007 21:40:28 org.apache.tuscany.sca.binding.ws.axis2.Axis2ServiceInOutSy ncMessageReceiver invokeBusinessLogic SEVERE: org.apache.tuscany.sca.databinding.TransformationException: com.sun.xml. bind.v2.runtime.IllegalAnnotationsException: 1 counts of IllegalAnnotationExcept ions java.lang.StackTraceElement does not have a no-arg default constructor. this problem is related to the following location: at java.lang.StackTraceElement at public java.lang.StackTraceElement[] java.lang.Throwable.getS tackTrace() at java.lang.Throwable at java.lang.Exception at com.example.BusinessException org.osoa.sca.ServiceRuntimeException: org.apache.tuscany.sca.databinding.Transfo rmationException: com.sun.xml.bind.v2.runtime.IllegalAnnotationsException: 1 cou nts of IllegalAnnotationExceptions java.lang.StackTraceElement does not have a no-arg default constructor. this problem is related to the following location: at java.lang.StackTraceElement at public java.lang.StackTraceElement[] java.lang.Throwable.getS tackTrace() at java.lang.Throwable at java.lang.Exception at com.example.BusinessException at org.apache.tuscany.sca.core.invocation.RuntimeWireInvoker.invoke(Runt imeWireInvoker.java:127) at org.apache.tuscany.sca.core.invocation.RuntimeWireInvoker.invoke(Runt imeWireInvoker.java:89) at org.apache.tuscany.sca.core.invocation.RuntimeWireInvoker.invoke(Runt imeWireInvoker.java:83) at org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.invoke(RuntimeWi reImpl.java:127) at org.apache.tuscany.sca.binding.ws.axis2.Axis2ServiceProvider.invokeTa rget(Axis2ServiceProvider.java:572) at org.apache.tuscany.sca.binding.ws.axis2.Axis2ServiceInOutSyncMessageR eceiver.invokeBusinessLogic(Axis2ServiceInOutSyncMessageReceiver.java:59) at org.apache.axis2.receivers.AbstractInOutSyncMessageReceiver.invokeBus
Re: Build failure in calculator-implementation-policies sample
HI,
Thanks Lee.
My apologies. I missed this out as I had located it elsewhere outside of my
local codebase. I'll fix this right away.
- Venkat
On Dec 17, 2007 8:56 PM, lee zhenghui [EMAIL PROTECTED] wrote:
Hi,
Just gave a try on this issue.. It is likely caused by missing jaas
configuration file. After did following steps manually. the sample can
work.
1. Create a jaas config file :
/** Login Configuration for the SCA-Calculator-Policies
sample
** for convenience, I am using NTLoginModule temporarily
**/
Calculator {
com.sun.security.auth.module.NTLoginModule required;
};
2. add jvm parameter: -Djava.security.auth.login.config=jaas.conf
3. Go to CalculatorCallbackHandler.java, modify the hardcode user/pw
to
correct one.
I am new to sca policy.. if I missed anything here, pls correct me.
On Dec 17, 2007 8:14 PM, Simon Nash [EMAIL PROTECTED] wrote:
I am getting the following error when building the latest trunk. Any
ideas?
Simon
[INFO]
-
---
[INFO] Building Apache Tuscany SCA Calculator Sample using
Implementation
Polici
es
[INFO]task-segment: [install]
[INFO]
-
---
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] Compiling 12 source files to
H:\tuscany58\sca\samples\calculator-implemen
tation-policies\target\classes
[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
[INFO] Compiling 1 source file to
H:\tuscany58\sca\samples\calculator-implementa
tion-policies\target\test-classes
[INFO] [surefire:test]
[INFO] Surefire report directory:
H:\tuscany58\sca\samples\calculator-implementa
tion-policies\target\surefire-reports
---
T E S T S
---
Running calculator.CalculatorTestCase
17-Dec-2007 11:28:27
org.apache.tuscany.sca.contribution.processor.ValidatingXML
StreamReader$1 error
WARNING: XMLSchema validation problem in:
file:/H:/tuscany58/sca/samples/calcula
tor-implementation-policies/target/classes/Calculator.composite, line:
28,
colum
n: 4
cvc-complex-type.2.4.a: Invalid content was found starting with element
'operati
on'. One of '{WC[##other:http://www.osoa.org/xmlns/sca/1.0]}' is
expected.
17-Dec-2007 11:28:28
INFO: Invoking operation - add
17-Dec-2007 11:28:28
FINER: Inovoking operation add with arguments 3.0, 2.0,
17-Dec-2007 11:28:28
INFO: Returned from operation - add
17-Dec-2007 11:28:28
FINER: Returning from operation add with return value 5
17-Dec-2007 11:28:28
INFO: Invoking operation - subtract
17-Dec-2007 11:28:28
FINER: Inovoking operation subtract with arguments 3.0, 2.0,
17-Dec-2007 11:28:28
INFO: Returned from operation - subtract
17-Dec-2007 11:28:28
FINER: Returning from operation subtract with return value 1
17-Dec-2007 11:28:28
org.apache.tuscany.sca.contribution.processor.ValidatingXML
StreamReader$1 error
WARNING: XMLSchema validation problem in:
file:/H:/tuscany58/sca/samples/calcula
tor-implementation-policies/target/classes/Calculator.composite, line:
28,
colum
n: 4
cvc-complex-type.2.4.a: Invalid content was found starting with element
'operati
on'. One of '{WC[##other:http://www.osoa.org/xmlns/sca/1.0]}' is
expected.
17-Dec-2007 11:28:28
INFO: Invoking operation - add
17-Dec-2007 11:28:28
FINER: Inovoking operation add with arguments 3.0, 2.0,
17-Dec-2007 11:28:28
INFO: Invoking operation - add
17-Dec-2007 11:28:28
FINER: Inovoking operation add with arguments 3.0, 2.0,
17-Dec-2007 11:28:28
INFO: Returned from operation - add
17-Dec-2007 11:28:28
FINER: Returning from operation add with return value 5
17-Dec-2007 11:28:28
INFO: Returned from operation - add
17-Dec-2007 11:28:28
FINER: Returning from operation add with return value 5
17-Dec-2007 11:28:28
INFO: Invoking operation - subtract
17-Dec-2007 11:28:28
FINER: Inovoking operation subtract with arguments 3.0, 2.0,
17-Dec-2007 11:28:28
INFO: Returned from operation - subtract
17-Dec-2007 11:28:28
FINER: Returning from operation subtract with return value 1
17-Dec-2007 11:28:28
INFO: Invoking operation - multiply
17-Dec-2007 11:28:28
FINER: Inovoking operation multiply with arguments 3.0, 2.0,
17-Dec-2007 11:28:28
INFO: Returned from operation - multiply
17-Dec-2007 11:28:28
FINER: Returning from operation multiply with return value
java.lang.RuntimeExce
ption: java.lang.SecurityException: Unable to locate a login
configuration
Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 1.462sec
FA
Re: Build failure in calculator-implementation-policies sample
Hi,
I've fixed this in r605107. I have added a section in the README as well
that should instruct on what is to be done to the java.security settings. I
have kept this to a minimum of having to make a line of change to the
java.security file.
Thanks
- Venkat
On Dec 18, 2007 10:41 AM, Venkata Krishnan [EMAIL PROTECTED] wrote:
HI,
Thanks Lee.
My apologies. I missed this out as I had located it elsewhere outside of
my local codebase. I'll fix this right away.
- Venkat
On Dec 17, 2007 8:56 PM, lee zhenghui [EMAIL PROTECTED] wrote:
Hi,
Just gave a try on this issue.. It is likely caused by missing jaas
configuration file. After did following steps manually. the sample can
work.
1. Create a jaas config file :
/** Login Configuration for the SCA-Calculator-Policies
sample
** for convenience, I am using NTLoginModule temporarily
**/
Calculator {
com.sun.security.auth.module.NTLoginModule required;
};
2. add jvm parameter: -Djava.security.auth.login.config=jaas.conf
3. Go to CalculatorCallbackHandler.java , modify the hardcode
user/pw to
correct one.
I am new to sca policy.. if I missed anything here, pls correct me.
On Dec 17, 2007 8:14 PM, Simon Nash [EMAIL PROTECTED] wrote:
I am getting the following error when building the latest trunk. Any
ideas?
Simon
[INFO]
-
---
[INFO] Building Apache Tuscany SCA Calculator Sample using
Implementation
Polici
es
[INFO]task-segment: [install]
[INFO]
-
---
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] Compiling 12 source files to
H:\tuscany58\sca\samples\calculator-implemen
tation-policies\target\classes
[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
[INFO] Compiling 1 source file to
H:\tuscany58\sca\samples\calculator-implementa
tion-policies\target\test-classes
[INFO] [surefire:test]
[INFO] Surefire report directory:
H:\tuscany58\sca\samples\calculator-implementa
tion-policies\target\surefire-reports
---
T E S T S
---
Running calculator.CalculatorTestCase
17-Dec-2007 11:28:27
org.apache.tuscany.sca.contribution.processor.ValidatingXML
StreamReader$1 error
WARNING: XMLSchema validation problem in:
file:/H:/tuscany58/sca/samples/calcula
tor-implementation-policies/target/classes/Calculator.composite, line:
28,
colum
n: 4
cvc-complex-type.2.4.a: Invalid content was found starting with
element
'operati
on'. One of '{WC[##other: http://www.osoa.org/xmlns/sca/1.0]}' is
expected.
17-Dec-2007 11:28:28
INFO: Invoking operation - add
17-Dec-2007 11:28:28
FINER: Inovoking operation add with arguments 3.0, 2.0,
17-Dec-2007 11:28:28
INFO: Returned from operation - add
17-Dec-2007 11:28:28
FINER: Returning from operation add with return value 5
17-Dec-2007 11:28:28
INFO: Invoking operation - subtract
17-Dec-2007 11:28:28
FINER: Inovoking operation subtract with arguments 3.0, 2.0,
17-Dec-2007 11:28:28
INFO: Returned from operation - subtract
17-Dec-2007 11:28:28
FINER: Returning from operation subtract with return value 1
17-Dec-2007 11:28:28
org.apache.tuscany.sca.contribution.processor.ValidatingXML
StreamReader$1 error
WARNING: XMLSchema validation problem in:
file:/H:/tuscany58/sca/samples/calcula
tor-implementation-policies/target/classes/Calculator.composite, line:
28,
colum
n: 4
cvc-complex-type.2.4.a : Invalid content was found starting with
element
'operati
on'. One of '{WC[##other:http://www.osoa.org/xmlns/sca/1.0]}' is
expected.
17-Dec-2007 11:28:28
INFO: Invoking operation - add
17-Dec-2007 11:28:28
FINER: Inovoking operation add with arguments 3.0, 2.0,
17-Dec-2007 11:28:28
INFO: Invoking operation - add
17-Dec-2007 11:28:28
FINER: Inovoking operation add with arguments 3.0, 2.0,
17-Dec-2007 11:28:28
INFO: Returned from operation - add
17-Dec-2007 11:28:28
FINER: Returning from operation add with return value 5
17-Dec-2007 11:28:28
INFO: Returned from operation - add
17-Dec-2007 11:28:28
FINER: Returning from operation add with return value 5
17-Dec-2007 11:28:28
INFO: Invoking operation - subtract
17-Dec-2007 11:28:28
FINER: Inovoking operation subtract with arguments 3.0, 2.0,
17-Dec-2007 11:28:28
INFO: Returned from operation - subtract
17-Dec-2007 11:28:28
FINER: Returning from operation subtract with return value 1
