[jira] [Created] (TUSCANY-4034) More memory leak fixes
More memory leak fixes -- Key: TUSCANY-4034 URL: https://issues.apache.org/jira/browse/TUSCANY-4034 Project: Tuscany Issue Type: Bug Affects Versions: Java-SCA-2.0-Beta3 Environment: All Reporter: Simon Laws Fix For: Java-SCA-2.0 Plugging variuous potential memory leaks. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TUSCANY-4028) Don't duplicate intents in Java implementation model
Don't duplicate intents in Java implementation model Key: TUSCANY-4028 URL: https://issues.apache.org/jira/browse/TUSCANY-4028 Project: Tuscany Issue Type: Bug Components: SCA Java Runtime Affects Versions: Java-SCA-2.0-Beta3 Environment: All Reporter: Simon Laws Fix For: Java-SCA-2.0 We have code in CompositeProcessor that caches intents and copies them back into the JavaImplementationModel. Add a check so that intents that are already present are not duplicated. I think this code is a hang over from when we used to share implementation models. If I remove it though I get test failures so for now I'm fixing the symptom. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TUSCANY-4025) Give registry contribution listeners a chance to retireve the contribution info before removing it
Give registry contribution listeners a chance to retireve the contribution info
before removing it
--
Key: TUSCANY-4025
URL: https://issues.apache.org/jira/browse/TUSCANY-4025
Project: Tuscany
Issue Type: Bug
Components: SCA Java Runtime
Affects Versions: Java-SCA-2.0-Beta3
Environment: All
Reporter: Simon Laws
Fix For: Java-SCA-2.0
In our DomainRegistryImpl class we have
public void uninstallContribution(String uri) {
contributionDescriptions.remove(uri);
for (ContributionListener listener : contributionlisteners) {
listener.contributionRemoved(uri);
}
}
It should wait until the listeners have been called before removing the
contribution description.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TUSCANY-4016) NodeImpl startComposite forgets about a composite if there is a failure on start
NodeImpl startComposite forgets about a composite if there is a failure on start
Key: TUSCANY-4016
URL: https://issues.apache.org/jira/browse/TUSCANY-4016
Project: Tuscany
Issue Type: Bug
Components: SCA Java Runtime
Affects Versions: Java-SCA-2.0-Beta3
Environment: All
Reporter: Simon Laws
org.apache.tuscany.sca.impl.NodeImpl does the following on start
public void startComposite(String contributionURI, String compositeURI)
throws ActivationException, ValidationException, ContributionReadException {
String key = contributionURI+/+compositeURI;
if (startedComposites.containsKey(key)) {
throw new IllegalStateException(composite already started: +
compositeURI);
}
DeployedComposite dc = stoppedComposites.remove(key);
if (dc != null) {
dc.start();
startedComposites.put(key, dc);
and the following on stop
String key = contributionURI+/+compositeURI;
DeployedComposite dc = startedComposites.remove(key);
if (dc != null) {
dc.stop();
stoppedComposites.put(key, dc);
} else {
If an error is thrown on start it won't be in startedComposites but some of the
providers may have been started. So even in the failure case we should consider
the composite partially started so that it can be stopped correctly.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TUSCANY-4013) Can't tell what binding URI the user provided in the SCDL after the builder has run as the BindingURIBuilder overwrites it
Can't tell what binding URI the user provided in the SCDL after the builder has run as the BindingURIBuilder overwrites it -- Key: TUSCANY-4013 URL: https://issues.apache.org/jira/browse/TUSCANY-4013 Project: Tuscany Issue Type: Bug Components: SCA Java Runtime Affects Versions: Java-SCA-2.0-Beta3 Environment: All Reporter: Simon Laws Priority: Minor Fix For: Java-SCA-2.0 The BindingURIBuilder overwrites any URI provided by the user so I propose to add a new field to binding (userSpecifiedURI) to hold what the user originally typed in. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TUSCANY-4014) Tidy up the binding model hierarchy
Tidy up the binding model hierarchy --- Key: TUSCANY-4014 URL: https://issues.apache.org/jira/browse/TUSCANY-4014 Project: Tuscany Issue Type: Improvement Components: SCA Java Runtime Affects Versions: Java-SCA-2.0-Beta3 Environment: All Reporter: Simon Laws Priority: Minor Fix For: Java-SCA-2.0 As per TUSCANY-4013 the binding model is all over the pace in terms of what extends what. We seem to have two base implementations, BindingImpl and BaseBindingImpl, and very few binding models choose to extend them for some reason. Would be good to tidy this up. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TUSCANY-4011) Callback binding gets overriden and other issues
Callback binding gets overriden and other issues Key: TUSCANY-4011 URL: https://issues.apache.org/jira/browse/TUSCANY-4011 Project: Tuscany Issue Type: Bug Components: SCA Java Runtime Affects Versions: Java-SCA-2.0-Beta3 Environment: All Reporter: Simon Laws Fix For: Java-SCA-2.0 I've noticed that any callback binding configuration provided in the SCDL is not present when the binding is used. It's because the binding is overridden by the callback endpoint created by the service binding. Only the URI is required so we can take this out of the binding created by the service binding and set it on the callback binding. In trying to work out what was going on here I noticed a couple of other things that I'd like to improve: - The code here is complicated by the thought that a single CallbackServiceReference might be used to contact multiple callback endpoints. This is no longer the case. For STATELESS components a new set of callback proxies (and hence CallbackServiceReference) is created for each new incoming message, because that's what happens with STATELESS components. For COMPOSITE components a new callback proxy is created for each call through the RequestContext object. Hence there is always a new CallbackServiceReference instance for each incoming call and related callback target. I believe the current complexity can be removed so that the CallbackServiceReference only every refers to one callback endpoint - There is an opportunity for further optimization if a binding is prepared to be responsible for resetting it's reference target address in the callback case. For example, if we provide a field in the forward message where a service binding can place the callback URI then we can remove the EPR clone in the CallbackServiceReference and have the callback reference binding take the target address out of the callback message. This need a bit of thought so I'll open a separate JIRA for it when I get to looking at it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TUSCANY-4012) Callback performance improvement
Callback performance improvement Key: TUSCANY-4012 URL: https://issues.apache.org/jira/browse/TUSCANY-4012 Project: Tuscany Issue Type: Improvement Components: SCA Java Runtime Affects Versions: Java-SCA-2.0-Beta3 Environment: All Reporter: Simon Laws Fix For: Java-SCA-2.0 Separating this out from TUSCANY-4011 - There is an opportunity to optimize callbacks if a binding implementation is prepared to be responsible for resetting it's reference target address in the callback case. For example, if we provide a field in the forward message where a service binding can place the callback URI then we can remove the EPR clone in the CallbackServiceReference and have the callback reference binding take the target address out of the callback message. The address will have to be cached in the CallbackServiceReference (or close by) so that when the callback message is sent the URI can be transmitted to the callback reference binding implementation which can then set/reset the target URI. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TUSCANY-4007) Mutliple delegations for binding.sca
Mutliple delegations for binding.sca Key: TUSCANY-4007 URL: https://issues.apache.org/jira/browse/TUSCANY-4007 Project: Tuscany Issue Type: Improvement Components: SCA Java Runtime Affects Versions: Java-SCA-2.x Environment: All Reporter: Simon Laws Fix For: Java-SCA-2.0 I've come across a situation where I'd like to support multiple remote delegations for a single binding.sca instance. This came up because I was looking at a situation where I wanted to support reliable and non-reliable comms at the same time so thought I would experiment with delegating to different underlying binding implementations. Currently the code doesn't allow you to do that as it assumes a local delegation and a single remote delegation are represented by the single binding.sca instance take from the component model. I've attached a patch with a fix to make this work. It creates a new endpoint for each required delegation. Am going to raise on the dev list before committing. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TUSCANY-4004) WSDL import handling creates definitions where the URI is set to the location which is different from the top level models
WSDL import handling creates definitions where the URI is set to the location
which is different from the top level models
--
Key: TUSCANY-4004
URL: https://issues.apache.org/jira/browse/TUSCANY-4004
Project: Tuscany
Issue Type: Improvement
Components: SCA Java Runtime
Affects Versions: Java-SCA-2.0-Beta3
Environment: All
Reporter: Simon Laws
Priority: Minor
Fix For: Java-SCA-2.0
There is code in WSDLModelResolver.resolveImports()
if
(unresolved.getNamespace().equals(resolved.getDefinition().getTargetNamespace()))
{
resolved.setNamespace(resolved.getDefinition().getTargetNamespace());
resolved.setUnresolved(false);
resolved.setURI(resolved.getLocation());
return modelClass.cast(resolved);
That puts the absolute location in the (usually relative) URI field. This was
causing me some confusion when debugging another issue as the imported WSDL
definition was constructed differently form the top level WSDL definition. I
don't know whether the imported WSDL absolutely must have this URI file set to
the location or whether it's just that the contribution relative URI is not
readily available in the part of the code.
As an aside, while looking that this, I notices that in
WSDLModelResolver.loadDefinition() there is a loop over the imports in order to
resolve the WSDLDefinition. All the unresolved definitions are represented by
the same WSDLDefinition object and the unresolved object becomes the resolved
object. This is likely to end in tears if there is more than one import.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TUSCANY-3996) Relative binding URIs not handled correctly when non-default root is specified
Relative binding URIs not handled correctly when non-default root is specified
--
Key: TUSCANY-3996
URL: https://issues.apache.org/jira/browse/TUSCANY-3996
Project: Tuscany
Issue Type: Bug
Components: SCA Java Runtime
Affects Versions: Java-SCA-2.x
Environment: All
Reporter: Simon Laws
Priority: Minor
Fix For: Java-SCA-2.x
There is code in the BindingURIBuilder as follows
if (baseURI == null) {
if (componentURI == null) {
if (bindingURI != null) {
uriString = name + / + bindingURI.toString();
} else {
uriString = name;
}
} else {
if (bindingURI != null) {
if (bindingURI.toString().startsWith(/)) {
uriString = componentURI.resolve(bindingURI).toString();
} else {
uriString = componentURI.resolve(name + / +
bindingURI).toString();
}
} else {
uriString = componentURI.resolve(name).toString();
}
}
} else {
if (componentURI == null) {
if (bindingURI != null) {
uriString = basedURI(baseURI, bindingURI).toString();
} else {
uriString = basedURI(baseURI, URI.create(name)).toString();
}
} else {
if (bindingURI != null) {
uriString = basedURI(baseURI,
componentURI.resolve(bindingURI)).toString();
} else {
uriString = basedURI(baseURI,
componentURI.resolve(name)).toString();
}
}
}
Note that the branch where baseURI is non-null behaves differently w.r.t.
adding name to the final URI compared to when baseURI is null.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TUSCANY-3960) Port JSR250 annotation processing over from 1.x
Port JSR250 annotation processing over from 1.x --- Key: TUSCANY-3960 URL: https://issues.apache.org/jira/browse/TUSCANY-3960 Project: Tuscany Issue Type: Improvement Components: SCA Java Runtime Affects Versions: Java-SCA-2.0-Beta3 Environment: All Reporter: Simon Laws Fix For: Java-SCA-2.0 AFAICT we haven't ported over the JSR250 annotation support yet. There is a complication here in that we must decide what to do with implementation level operation policy configuration. I'll populate the implementation level operation list and see if that works out. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TUSCANY-3961) EndpointReferenceBuilder relies on internal exception throwing
EndpointReferenceBuilder relies on internal exception throwing
--
Key: TUSCANY-3961
URL: https://issues.apache.org/jira/browse/TUSCANY-3961
Project: Tuscany
Issue Type: Improvement
Components: SCA Java Runtime
Affects Versions: Java-SCA-2.0-Beta3
Environment: All
Reporter: Simon Laws
Fix For: Java-SCA-2.0
The EndpointReferenceBuilderImpl uses this code when it's trying to decide if a
target is a domain target or not.
try {
getSCATargetParts(uri);
// the target uri might be an SCA target so create an
endpoint
// so that the binder can test it against the fully
populated
// registry
endpoint = createEndpoint(component, uri);
if (binding instanceof SCABinding) {
// TUSCANY-3941
// if it's an SCA binding we store it to influence
the matching at runtime
endpointRef.setBinding(binding);
}
endpointRef.setStatus(EndpointReference.Status.WIRED_TARGET_IN_BINDING_URI);
} catch (Exception ex) {
// the target string definitely isn't an SCA target
string
// so we can assume here that the user has configured a
// resolved binding
endpoint = createEndpoint(false);
endpoint.setURI(uri);
endpoint.setBinding(binding);
endpointRef.setStatus(EndpointReference.Status.RESOLVED_BINDING);
}
Seems a bit missleading and I want change so we don't rely on internal
exception throwing.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
