[jira] Created: (TUSCANY-2392) Enable debug tracing in Tuscany
Enable debug tracing in Tuscany --- Key: TUSCANY-2392 URL: https://issues.apache.org/jira/browse/TUSCANY-2392 Project: Tuscany Issue Type: Wish Components: Build System Reporter: Jean-Sebastien Delfino Fix For: Java-SCA-Next We've never really concluded the discussion on enabling some form of debug trace in Tuscany. Having built a number of samples, tutorials and applications with Tuscany, I think we need a way to trace through the runtime to understand when something goes wrong. I would like to see the following implemented: - direct calls to JDK logger (without an intermediate layer on top of JDK logger) - generated using aspectj - no hard dependency on aspectj in the Tuscany distribution, but instead steps describing how to enable it as already described here: http://marc.info/?l=tuscany-devm=118841084129220 and demonstrated by Raymond there: http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/rfeng/aop-logging/ Disclaimer: this issue is not about monitoring which is a different subject and properly covered in the runtime at the moment IMO with the work that Simon and Ramkumar have done. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TUSCANY-2393) Complete Atom binding implementation
Complete Atom binding implementation Key: TUSCANY-2393 URL: https://issues.apache.org/jira/browse/TUSCANY-2393 Project: Tuscany Issue Type: Wish Components: Java SCA ATOM Binding Extension Reporter: Jean-Sebastien Delfino Fix For: Java-SCA-Next I would like to see the following features completed in the Tuscany Atom binding: - support for eTags, last-modified headers, complete support for location header - on the client side, caching using eTag and/or lastModified - the ability to negociate content types (XML, JSON etc) and use the corresponding Tuscany databindings to provide data with the requested content type - support for postMedia and putMedia, including the ability to stream that content in the target application component - support for security as required by the Atompub spec, and mapping between the security features and corresponding SCA security policies - complete generation of an AtomPub workspace/service document, for a service, component or a group of related components (potentially in a composite), somebody should study this to find the correct granularity level - samples/scenarios that help us explore how to implement relationships between two (Atom) collections of resources (e.g. Customer and Account, with a Customer owning multiple Accounts) - A proper Javascript object model for an Atom collection and Atom entries to facilitate the use of Atom in Javascript clients, modeled after the Abdera model for collection and entry. - A Javascript model for Atom collections and entries mirroring the Tuscany Java data.Collection interface, providing simple access to business data objects in an Atom collection. - Finally somebody should do a pass through the Atom and AtomPub specs and make sure that we're not missing any big feature from the spec. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TUSCANY-2394) JSON-RPC binding improvements
JSON-RPC binding improvements - Key: TUSCANY-2394 URL: https://issues.apache.org/jira/browse/TUSCANY-2394 Project: Tuscany Issue Type: Wish Components: Java SCA JSON-RPC Binding Extension Reporter: Jean-Sebastien Delfino Fix For: Java-SCA-Next I would like to see the following improvements made to the JSON-RPC binding: - Support for security (this will require exploratory work to understand what SCA security policies make sense to implement) - Business Exception reporting, business exceptions raised by a service should be transported to the client through JSON and reported to the client as proper Javascript business exceptions - Better runtime exception reporting, runtime exceptions occurring as part of a JSON-RPC interaction should be properly reported to the Javascript client. - Complete data binding support, a set of test cases should be written to make sure that the POJO and JAXB patterns supported in Java components have a proper mapping to JSON and that the application developer can easily understand the corresponding representation of these objects in Javascript. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TUSCANY-2393) Complete Atom binding implementation
[ https://issues.apache.org/jira/browse/TUSCANY-2393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12605406#action_12605406 ] Jean-Sebastien Delfino commented on TUSCANY-2393: - One more requirement: Better error reporting: - a mapping between common runtime errors and HTTP status codes should be defined - somebody should investigate how to map business exceptions to Atom responses (or define a fixed set of business exceptions that can be reported, like we've done for the NotFoundException) - the Atom Javascript client proxy should report these exceptions in a usable form to the Javascript client program. Complete Atom binding implementation Key: TUSCANY-2393 URL: https://issues.apache.org/jira/browse/TUSCANY-2393 Project: Tuscany Issue Type: Wish Components: Java SCA ATOM Binding Extension Reporter: Jean-Sebastien Delfino Fix For: Java-SCA-Next I would like to see the following features completed in the Tuscany Atom binding: - support for eTags, last-modified headers, complete support for location header - on the client side, caching using eTag and/or lastModified - the ability to negociate content types (XML, JSON etc) and use the corresponding Tuscany databindings to provide data with the requested content type - support for postMedia and putMedia, including the ability to stream that content in the target application component - support for security as required by the Atompub spec, and mapping between the security features and corresponding SCA security policies - complete generation of an AtomPub workspace/service document, for a service, component or a group of related components (potentially in a composite), somebody should study this to find the correct granularity level - samples/scenarios that help us explore how to implement relationships between two (Atom) collections of resources (e.g. Customer and Account, with a Customer owning multiple Accounts) - A proper Javascript object model for an Atom collection and Atom entries to facilitate the use of Atom in Javascript clients, modeled after the Abdera model for collection and entry. - A Javascript model for Atom collections and entries mirroring the Tuscany Java data.Collection interface, providing simple access to business data objects in an Atom collection. - Finally somebody should do a pass through the Atom and AtomPub specs and make sure that we're not missing any big feature from the spec. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TUSCANY-2395) SCA default binding should not depend on the whole Web Service binding
SCA default binding should not depend on the whole Web Service binding -- Key: TUSCANY-2395 URL: https://issues.apache.org/jira/browse/TUSCANY-2395 Project: Tuscany Issue Type: Wish Components: Java SCA Core Runtime Reporter: Jean-Sebastien Delfino Fix For: Java-SCA-Next The SCA default binding is currently just wrapping the Web Service binding. I don't think that it's right as the Web Service binding is now starting to have to support more styles / variations than needed by the SCA default binding. IMO the SCA default binding should be a 'strict minimum' implementation of a SOAP WS-I basic profile doc-literal-wrapped binding, and not depend of the Web Service binding code, which will need to evolve to support many more styles. This will also allow people who are not interested in Web Services and do not want to install the richer Web Service binding to use a simpler / more lightweight binding. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TUSCANY-2396) Model and runtime should be in separate modules
Model and runtime should be in separate modules --- Key: TUSCANY-2396 URL: https://issues.apache.org/jira/browse/TUSCANY-2396 Project: Tuscany Issue Type: Wish Components: Build System Reporter: Jean-Sebastien Delfino Fix For: Java-SCA-Next A number of extensions are still putting their model and runtime implementation in a single module. This makes them difficult to use in: - development tools - deployment tools - administration applications - nodes which need to load and inspect composites without necessarily running all their contents We've done some refactoring work on a number of implementation and binding extensions. The following modules still need to be refactored: - dwr - jms - notification - rmi - osgi - script - spring - xquery When doing that, the dwr, rmi, and script extensions should be migrated from the extension-helper to the assembly and core-spi SPI used by all other extensions, as extension-helper doesn't provide the proper separation between model and runtime. More extensions which I'm not sure about as they are not in Tuscany distributions: - das - data-xml - openjpa -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TUSCANY-2397) Binding corba should use a host-corba module
Binding corba should use a host-corba module Key: TUSCANY-2397 URL: https://issues.apache.org/jira/browse/TUSCANY-2397 Project: Tuscany Issue Type: Wish Components: Java SCA Misc Binding Extensions Reporter: Jean-Sebastien Delfino Fix For: Java-SCA-Next In order to allow an ORB instance to be shared by multiple services/references with Corba bindings, two new modules should be created. - Host-corba should define a Host interface for Corba ORBs, allowing Corba service binding providers to register Corba servants with an ORB. - Host-corba-jdk should implement that Host interface using the JDK ORB. Another Host-corba-yoko could be created later for an implementation of that Host interface using Yoko, which may be handy in a Geronimo environment for example. That approach is similar to the approach we've taken for HTTP with: - Host-http the extension interface for HTTP hosts - Host-jetty and Host-tomcat, implementations using Jetty and Tomcat. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TUSCANY-2215) Destory method is not called if scope type is request
[
https://issues.apache.org/jira/browse/TUSCANY-2215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12604979#action_12604979
]
Jean-Sebastien Delfino commented on TUSCANY-2215:
-
The problem is that the runtime currently does not track the lifecycle of
requests and therefore has no way to detect the end of a request.
I think that the following needs to be done:
- Define a proper eventing mechanism (at the moment the stuff in
org.apache.tuscany.sca.core.event is not used) to signal lifecycle events on
composite, conversation, request and stateless scopes
- Use this mechanism consistently in to track the state of these scopes (the
different scope containers seem to be using different mechanisms at the moment,
for example ConversationalScopeContainer has introduced a set of specific
eventing methods, which the other scopes do not use).
- Make sure that entry / exit points (e.g binding providers) send the right
begin/end scope events, this is not in place at all at the moment, except for
conversation events in some specific cases.
I recommend a serious cleanup of the whole event mechanism (which could
potentially be rewritten as it's not used and mostly dead code anyway), the
scope management mechanism, and a pass through all binding providers and
component implementation providers to ensure that they generate or react to
scope events correctly.
As a starting point, the Event and Scope interfaces are SPIs, they should be in
a different package, in a different module: core-spi.
Destory method is not called if scope type is request
-
Key: TUSCANY-2215
URL: https://issues.apache.org/jira/browse/TUSCANY-2215
Project: Tuscany
Issue Type: Bug
Components: Java SCA Core Runtime
Affects Versions: Java-SCA-Next
Reporter: Gilbert Kwan
Fix For: Java-SCA-Next
Destroy method was not called for @Scope(REQUEST).
Service Definition:
=
@Scope(REQUEST)
public class AServiceImpl implements AService {
@Init
public void init() {
System.out.println(init());
}
@Destroy
public void destroy() {
System.out.println(destroy());
}
public void xxx() {
System.out.println(xxx());}
}
Client called:
=
System.out.println(Setting up);
domain = SCADomain.newInstance(compositeName);
aService = domain.getService(AService.class, AService);
aService.xxx();
System.out.println(Cleaning up);
if (domain != null)
domain.close();
Output:
==
Setting up
init()
xxx()
Cleaning up
When changed to other scope type, the destroy method could be called.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (TUSCANY-2380) Modular distribution structure
Modular distribution structure -- Key: TUSCANY-2380 URL: https://issues.apache.org/jira/browse/TUSCANY-2380 Project: Tuscany Issue Type: Wish Components: Build System Reporter: Jean-Sebastien Delfino Fix For: Java-SCA-Next I have described the kind of distribution structure that I'd like to have on the dev list there: http://marc.info/?l=tuscany-devm=121306338517687 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TUSCANY-2381) Detect extensions installed in a Tuscany distribution
Detect extensions installed in a Tuscany distribution - Key: TUSCANY-2381 URL: https://issues.apache.org/jira/browse/TUSCANY-2381 Project: Tuscany Issue Type: Wish Components: Build System Reporter: Jean-Sebastien Delfino Fix For: Java-SCA-Next I think that Tuscany users and application developers should not have to worry about which Tuscany JARs they are using. I've described what I'd like to see as a user on the tuscany-dev list there: http://marc.info/?l=tuscany-devm=121311590032485 Eclipse Equinox provides a good way to achieve that (detect and track extensions of a runtime core) in an OSGi environment. I'd like to use it as an option of our current extension discovery mechanism (currently based on META-INF/services declarations). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TUSCANY-181) Need a command line tool and maven2 plugin to validate an SCA assembly
[ https://issues.apache.org/jira/browse/TUSCANY-181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino updated TUSCANY-181: --- Issue Type: New Feature (was: Wish) Need a command line tool and maven2 plugin to validate an SCA assembly -- Key: TUSCANY-181 URL: https://issues.apache.org/jira/browse/TUSCANY-181 Project: Tuscany Issue Type: New Feature Components: Java SCA Tools Reporter: Jean-Sebastien Delfino Priority: Minor Fix For: Java-SCA-Next We need a command line tool and a maven2 plugin to validate an SCA assembly. This is important to help application developers detect and diagnose problems in their assembly before they deploy and run the application. This tool should take an SCA assembly (module or subsytem) and run a set of validation rules on its artifacts. - XML schema validation on the SCDL artifacts - semantic validation on the assembly model (e.g. verify that an interface declared on a service actually exists, verify that a wire can actually be resolved) The tool should generate messages with enough context information, including file name, line number, and relevant assembly model objects. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TUSCANY-2382) Endpoint model changes
Endpoint model changes --- Key: TUSCANY-2382 URL: https://issues.apache.org/jira/browse/TUSCANY-2382 Project: Tuscany Issue Type: Wish Components: Build System Reporter: Jean-Sebastien Delfino I'd like to suggest the following changes to the Endpoint model, described in this email to the dev list: http://marc.info/?l=tuscany-devm=121312087509203 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TUSCANY-2382) Endpoint model changes
[ https://issues.apache.org/jira/browse/TUSCANY-2382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino updated TUSCANY-2382: Fix Version/s: Java-SCA-Next Endpoint model changes --- Key: TUSCANY-2382 URL: https://issues.apache.org/jira/browse/TUSCANY-2382 Project: Tuscany Issue Type: Wish Components: Build System Reporter: Jean-Sebastien Delfino Fix For: Java-SCA-Next I'd like to suggest the following changes to the Endpoint model, described in this email to the dev list: http://marc.info/?l=tuscany-devm=121312087509203 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (TUSCANY-2342) Problems in BaseStAXArtifactProcessor with writing prefixes
[
https://issues.apache.org/jira/browse/TUSCANY-2342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jean-Sebastien Delfino reassigned TUSCANY-2342:
---
Assignee: Jean-Sebastien Delfino
Problems in BaseStAXArtifactProcessor with writing prefixes
---
Key: TUSCANY-2342
URL: https://issues.apache.org/jira/browse/TUSCANY-2342
Project: Tuscany
Issue Type: Bug
Components: Java SCA Assembly Model
Reporter: Greg Dritschler
Assignee: Jean-Sebastien Delfino
I think that BaseStAXArtifactProcessor has some bugs related to writing
namespace prefixes for attribute values.
Let's start with this method:
protected void writeStart(XMLStreamWriter writer, String uri, String
name, XAttr... attrs) throws XMLStreamException {
String prefix = writeElementPrefix(writer, uri);
writeAttributePrefixes(writer, attrs);
writer.writeStartElement(uri, name);
if (prefix != null){
writer.writeNamespace(prefix,uri);
}
writeAttributes(writer, attrs);
}
writeAttributePrefixes calls down to XAttr.writePrefix.
If the value is a QName then XAttr.writePrefix calls XAttr.writeQNamePrefix.
private void writeQNamePrefix(XMLStreamWriter writer, QName qname)
throws XMLStreamException {
if (qname != null) {
String prefix = qname.getPrefix();
String uri = qname.getNamespaceURI();
prefix = writer.getPrefix(uri);
if (prefix != null) {
return;
} else {
// Find an available prefix and bind it to the given URI
NamespaceContext nsc = writer.getNamespaceContext();
for (int i=1; ; i++) {
prefix = ns + i;
if (nsc.getNamespaceURI(prefix) == null) {
break;
}
}
writer.setPrefix(prefix, uri);
}
}
}
If the QName has a uri which isn't yet bound to a prefix, this method binds
it. Note that it does not write the namespace to the stream, nor does it
return anything to its caller to tell it to write the namespace. So the
resulting XML has an unbound prefix which will cause problems for anyone
re-reading the composite.
writeQNamePrefix cannot write the namespace itself because it is being called
by writeStart before the element has been started. If this is the root
element of the document, attempting to do a write at this point will cause an
exception.
I'm not sure why the code is arranged this way. I thought it might be to
minimize the number of prefixes generated by binding the prefix in the
parent's element rather than the element we are about to write. But that
doesn't work when you are working with the root element and don't have a
parent element.
So I don't know why this structure of separately writing the prefixes is
here. XAttr.writeQNameValue has code to bind a prefix to a new URI, and it
DOES write the prefix-uri binding to the stream. Why isn't that good enough?
Speaking of writeQNameValue, I have a question about it too.
private String writeQNameValue(XMLStreamWriter writer, QName qname)
throws XMLStreamException {
if (qname != null) {
String prefix = qname.getPrefix();
String uri = qname.getNamespaceURI();
prefix = writer.getPrefix(uri);
if (prefix != null prefix.length() 0) {
// Use the prefix already bound to the given URI
return prefix + : + qname.getLocalPart();
} else {
// Find an available prefix and bind it to the given URI
NamespaceContext nsc = writer.getNamespaceContext();
for (int i=1; ; i++) {
prefix = ns + i;
if (nsc.getNamespaceURI(prefix) == null) {
break;
}
}
writer.setPrefix(prefix, uri);
writer.writeNamespace(prefix, uri);
return prefix + : + qname.getLocalPart();
}
} else {
return null;
}
}
I am wondering about the check for prefix.length() 0. The documentation
for getPrefix() is sketchy, but it seems to return the empty string if the
given namespace is the default namespace. So this code generates a new
prefix when the QName value uses the default namespace. Why does it do that?
I think if
[jira] Resolved: (TUSCANY-2342) Problems in BaseStAXArtifactProcessor with writing prefixes
[
https://issues.apache.org/jira/browse/TUSCANY-2342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jean-Sebastien Delfino resolved TUSCANY-2342.
-
Resolution: Fixed
I looked into this and observed the following:
1. the code was designed to work with XMLOutputFactory.IS_REPAIRING_NAMESPACES
= true, making the XMLOutputFactory responsible for writing the namespace
prefix declarations for the namespaces in context and making sure that one
prefix is declared per namespace used in elements and attributes.
2. since we were not writing the namespaces ourselves we didn't have a problem
with namespace prefix declarations being written in the parent element (since
the XMLOutputFactory was generating them in the correct element context)
3. we had to handle the writing of namespace declarations ourselves when
writing QName attribute values as IS_REPAIRING_NAMESPACES does not cover that
case (it only handles namespaces in element and attribute names)
4. in that code we used to generate an unnecessary namespace prefix for the
default namespace (as we did not recognize that prefix == was referring to
the default namespace), this was a non-breaking bug.
I fixed (4).
I also changed the code a little to call XAttr.setPrefix after
writeStartElement() and explicitly call writeNamespace() for namespaces in
attribute names.
This should have not have a visible effect with an XMLOutputFactory configured
with IS_REPAIRING_NAMESPACES = true, but should now generate namespace prefix
declarations with an XMLOutputFactory not using that option.
I recommend using IS_REPAIRING_NAMESPACES anyway as it handles duplicate
namespace prefix declarations better, and is also the option we set by default
in the Tuscany runtime.
Problems in BaseStAXArtifactProcessor with writing prefixes
---
Key: TUSCANY-2342
URL: https://issues.apache.org/jira/browse/TUSCANY-2342
Project: Tuscany
Issue Type: Bug
Components: Java SCA Assembly Model
Reporter: Greg Dritschler
Assignee: Jean-Sebastien Delfino
I think that BaseStAXArtifactProcessor has some bugs related to writing
namespace prefixes for attribute values.
Let's start with this method:
protected void writeStart(XMLStreamWriter writer, String uri, String
name, XAttr... attrs) throws XMLStreamException {
String prefix = writeElementPrefix(writer, uri);
writeAttributePrefixes(writer, attrs);
writer.writeStartElement(uri, name);
if (prefix != null){
writer.writeNamespace(prefix,uri);
}
writeAttributes(writer, attrs);
}
writeAttributePrefixes calls down to XAttr.writePrefix.
If the value is a QName then XAttr.writePrefix calls XAttr.writeQNamePrefix.
private void writeQNamePrefix(XMLStreamWriter writer, QName qname)
throws XMLStreamException {
if (qname != null) {
String prefix = qname.getPrefix();
String uri = qname.getNamespaceURI();
prefix = writer.getPrefix(uri);
if (prefix != null) {
return;
} else {
// Find an available prefix and bind it to the given URI
NamespaceContext nsc = writer.getNamespaceContext();
for (int i=1; ; i++) {
prefix = ns + i;
if (nsc.getNamespaceURI(prefix) == null) {
break;
}
}
writer.setPrefix(prefix, uri);
}
}
}
If the QName has a uri which isn't yet bound to a prefix, this method binds
it. Note that it does not write the namespace to the stream, nor does it
return anything to its caller to tell it to write the namespace. So the
resulting XML has an unbound prefix which will cause problems for anyone
re-reading the composite.
writeQNamePrefix cannot write the namespace itself because it is being called
by writeStart before the element has been started. If this is the root
element of the document, attempting to do a write at this point will cause an
exception.
I'm not sure why the code is arranged this way. I thought it might be to
minimize the number of prefixes generated by binding the prefix in the
parent's element rather than the element we are about to write. But that
doesn't work when you are working with the root element and don't have a
parent element.
So I don't know why this structure of separately writing the prefixes is
here. XAttr.writeQNameValue has code to bind a prefix to a new URI, and it
DOES write the prefix-uri binding to the stream. Why isn't that good enough?
Speaking of
[jira] Updated: (TUSCANY-2182) ClassLoader issues with node2 launcher on WebSphere
[ https://issues.apache.org/jira/browse/TUSCANY-2182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino updated TUSCANY-2182: Comment: was deleted ClassLoader issues with node2 launcher on WebSphere --- Key: TUSCANY-2182 URL: https://issues.apache.org/jira/browse/TUSCANY-2182 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-1.2 Reporter: Jean-Sebastien Delfino Assignee: Jean-Sebastien Delfino Fix For: Java-SCA-1.2 The classloader used by Node2 uses a parent-first loading scheme which does not work on WebSphere application server, as different versions of the Tuscany runtime dependencies are on the classpath of Webapps in the WebSphere environment. The fix for that issue is simply to ensure that the Node2 launcher uses a parent-last classloading scheme to load its runtime classes. -- 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] Commented: (TUSCANY-2182) ClassLoader issues with node2 launcher on WebSphere
[ https://issues.apache.org/jira/browse/TUSCANY-2182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12586036#action_12586036 ] Jean-Sebastien Delfino commented on TUSCANY-2182: - Here are the steps to get webapps that use the node2 launcher (see tutorial/catalog-webapp for an example) working on WebSphere using a WebSphere shared library for the Tuscany JARs. 1. Copy the following JARs from the Tuscany distribution lib directory to the WebSphere lib/ext directory: jaxb2-reflection-2.1.4.jar jaxb-api-2.1.jar jaxb-impl-2.1.6.jar jaxb-xjc-2.1.4.jar stax-api-1.0-2.jar xercesImpl-2.8.1.jar 2. Create a WebSphere shared library for Tuscany containing the following JARs from the Tuscany distribution lib and modules directories. NOTE this is a SUBSET of the JARs in the Tuscany distribution, carefully selected to avoid conflicts with the JARs from WebSphere and the JDK that it uses: /tuscany/lib/abdera-core-0.3.0-incubating.jar /tuscany/lib/abdera-i18n-0.3.0-incubating.jar /tuscany/lib/abdera-parser-0.3.0-incubating.jar /tuscany/lib/activation-1.1.jar /tuscany/lib/activeio-2.0-r118.jar /tuscany/lib/activeio-core-3.0.0-incubator.jar /tuscany/lib/annogen-0.1.0.jar /tuscany/lib/annotations-api-6.0.14.jar /tuscany/lib/aopalliance-1.0.jar /tuscany/lib/apache-activemq-4.1.1.jar /tuscany/lib/axiom-api-1.2.5.jar /tuscany/lib/axiom-dom-1.2.5.jar /tuscany/lib/axiom-impl-1.2.5.jar /tuscany/lib/axion-1.0-M3-dev.jar /tuscany/lib/axis2-adb-1.3.jar /tuscany/lib/axis2-codegen-1.3.jar /tuscany/lib/axis2-java2wsdl-1.3.jar /tuscany/lib/axis2-kernel-1.3.jar /tuscany/lib/axis2-mtompolicy-1.3.jar /tuscany/lib/backport-util-concurrent-2.1.jar /tuscany/lib/bcprov-jdk13-132.jar /tuscany/lib/bsf-all-3.0-beta2.jar /tuscany/lib/cglib-nodep-2.1_3.jar /tuscany/lib/codegen-2.2.3.jar /tuscany/lib/codegen-ecore-2.2.3.jar /tuscany/lib/common-2.2.3.jar /tuscany/lib/commons-beanutils-1.6.1.jar /tuscany/lib/commons-codec-1.3.jar /tuscany/lib/commons-collections-3.1.jar /tuscany/lib/commons-discovery-0.2.jar /tuscany/lib/commons-fileupload-1.1.1.jar /tuscany/lib/commons-httpclient-3.0.1.jar /tuscany/lib/commons-io-1.2.jar /tuscany/lib/commons-jexl-1.1.jar /tuscany/lib/commons-lang-2.1.jar /tuscany/lib/commons-logging-1.1.jar /tuscany/lib/commons-primitives-1.0.jar /tuscany/lib/derby-10.1.3.1.jar /tuscany/lib/dom4j-1.6.1.jar /tuscany/lib/dwr-2.0.1.jar /tuscany/lib/ecore-2.2.3.jar /tuscany/lib/ecore-change-2.2.3.jar /tuscany/lib/ecore-xmi-2.2.3.jar /tuscany/lib/geronimo-activation_1.0.2_spec-1.1.jar /tuscany/lib/geronimo-activation_1.1_spec-1.0-M1.jar /tuscany/lib/geronimo-common-1.2-beta.jar /tuscany/lib/geronimo-commonj_1.1_spec-1.0.jar /tuscany/lib/geronimo-connector-1.2-beta.jar /tuscany/lib/geronimo-core-1.2-beta.jar /tuscany/lib/geronimo-deployment-1.2-beta.jar /tuscany/lib/geronimo-ejb_3.0_spec-1.0.jar /tuscany/lib/geronimo-interceptor-1.2-beta.jar /tuscany/lib/geronimo-j2ee-1.2-beta.jar /tuscany/lib/geronimo-j2ee-connector_1.5_spec-1.0.jar /tuscany/lib/geronimo-j2ee-jacc_1.0_spec-1.0.jar /tuscany/lib/geronimo-j2ee-management_1.0_spec-1.0.jar /tuscany/lib/geronimo-javamail_1.4_spec-1.0-M1.jar /tuscany/lib/geronimo-jms_1.1_spec-1.0.jar /tuscany/lib/geronimo-jpa_3.0_spec-1.0.jar /tuscany/lib/geronimo-jta_1.0.1B_spec-1.0.jar /tuscany/lib/geronimo-kernel-1.2-beta.jar /tuscany/lib/geronimo-management-1.2-beta.jar /tuscany/lib/geronimo-naming-1.2-beta.jar /tuscany/lib/geronimo-security-1.2-beta.jar /tuscany/lib/geronimo-spec-j2ee-connector-1.5-rc4.jar /tuscany/lib/geronimo-spec-jta-1.0.1B-rc4.jar /tuscany/lib/geronimo-system-1.2-beta.jar /tuscany/lib/geronimo-transaction-1.2-beta.jar /tuscany/lib/geronimo-util-1.2-beta.jar /tuscany/lib/groovy-all-minimal-1.5.4.jar /tuscany/lib/howl-1.0.1-1.jar /tuscany/lib/httpcore-4.0-alpha5.jar /tuscany/lib/httpcore-nio-4.0-alpha5.jar /tuscany/lib/httpcore-niossl-4.0-alpha5.jar /tuscany/lib/javacc-3.2.jar /tuscany/lib/jaxen-1.1.1.jar /tuscany/lib/jaxws-api-2.1.jar /tuscany/lib/jdom-1.0.jar /tuscany/lib/jettison-1.0-RC2.jar /tuscany/lib/jmdns-1.0-RC2.jar /tuscany/lib/jrms-1.1.jar /tuscany/lib/jruby-complete-1.0.jar /tuscany/lib/json-rpc-1.0.jar /tuscany/lib/jsr181-api-1.0-MR1.jar /tuscany/lib/jsr250-api-1.0.jar /tuscany/lib/juli-6.0.14.jar /tuscany/lib/jython-2.2.jar /tuscany/lib/log4j-1.2.12.jar /tuscany/lib/logkit-1.0.1.jar /tuscany/lib/mx4j-2.1.1.jar /tuscany/lib/mx4j-remote-2.1.1.jar /tuscany/lib/neethi-2.0.2.jar /tuscany/lib/ode-bpel-api-1.1.jar /tuscany/lib/ode-bpel-compiler-1.1.jar /tuscany/lib/ode-bpel-dao-1.1.jar /tuscany/lib/ode-bpel-epr-1.1.jar /tuscany/lib/ode-bpel-obj-1.1.jar /tuscany/lib/ode-bpel-runtime-1.1.jar /tuscany/lib/ode-bpel-schemas-1.1.jar /tuscany/lib/ode-bpel-store-1.1.jar /tuscany/lib/ode-dao-jpa-1.1.jar /tuscany/lib/ode-dao-jpa-ojpa-derby-1.1.zip /tuscany/lib/ode-jacob-1.1.jar /tuscany/lib/ode-jacob-ap-1.1.jar /tuscany/lib/ode-scheduler-simple-1.1.jar /tuscany/lib/ode-utils-1.1.jar
[jira] Commented: (TUSCANY-2200) Sample calculator-webapp fails in WAS 6.1
[ https://issues.apache.org/jira/browse/TUSCANY-2200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12586039#action_12586039 ] Jean-Sebastien Delfino commented on TUSCANY-2200: - Could you guys please check your WebSphere install? I'm not sure how that affects that issue but on my installation xalan is already in the lib/ext directory. Sample calculator-webapp fails in WAS 6.1 - Key: TUSCANY-2200 URL: https://issues.apache.org/jira/browse/TUSCANY-2200 Project: Tuscany Issue Type: Bug Components: Java SCA Samples Affects Versions: Java-SCA-1.2 Reporter: Luciano Resende Fix For: Java-SCA-1.2 Exception = org.osoa.sca.ServiceRuntimeException Source = com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.init probeid = 111 Stack Dump = org.osoa.sca.ServiceRuntimeException: java.lang.reflect.InvocationTargetException at org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:264) at org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SCADomain.java:82) at org.apache.tuscany.sca.host.webapp.WebAppServletHost.init(WebAppServletHost.java:216) at org.apache.tuscany.sca.host.webapp.TuscanyServletFilter.init(TuscanyServletFilter.java:50) at com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.init(FilterInstanceWrapper.java:142) at com.ibm.ws.webcontainer.filter.WebAppFilterManager._loadFilter(WebAppFilterManager.java:465) at com.ibm.ws.webcontainer.filter.WebAppFilterManager.loadFilter(WebAppFilterManager.java:379) at com.ibm.ws.webcontainer.filter.WebAppFilterManager.getFilterInstanceWrapper(WebAppFilterManager.java:238) at com.ibm.ws.webcontainer.filter.WebAppFilterManager.getFilterChain(WebAppFilterManager.java:296) at com.ibm.ws.webcontainer.filter.WebAppFilterManager.doFilter(WebAppFilterManager.java:721) at com.ibm.ws.webcontainer.filter.WebAppFilterManager.doFilter(WebAppFilterManager.java:673) at com.ibm.ws.webcontainer.filter.WebAppFilterManager.invokeFilters(WebAppFilterManager.java:688) at com.ibm.ws.wswebcontainer.filter.WebAppFilterManager.invokeFilters(WebAppFilterManager.java:101) at com.ibm.ws.webcontainer.extension.DefaultExtensionProcessor.invokeFilters(DefaultExtensionProcessor.java:758) at com.ibm.ws.webcontainer.extension.DefaultExtensionProcessor.handleRequest(DefaultExtensionProcessor.java:471) at com.ibm.ws.wswebcontainer.extension.DefaultExtensionProcessor.handleRequest(DefaultExtensionProcessor.java:113) at com.ibm.ws.webcontainer.webapp.WebApp.handleRequest(WebApp.java:3276) at com.ibm.ws.webcontainer.webapp.WebGroup.handleRequest(WebGroup.java:267) at com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:811) at com.ibm.ws.wswebcontainer.WebContainer.handleRequest(WebContainer.java:1455) at com.ibm.ws.webcontainer.channel.WCChannelLink.ready(WCChannelLink.java:113) at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleDiscrimination(HttpInboundLink.java:454) at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleNewInformation(HttpInboundLink.java:383) at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.ready(HttpInboundLink.java:263) at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.sendToDiscriminators(NewConnectionInitialReadCallback.java:214) at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.complete(NewConnectionInitialReadCallback.java:113) at com.ibm.ws.tcp.channel.impl.AioReadCompletionListener.futureCompleted(AioReadCompletionListener.java:165) at com.ibm.io.async.AbstractAsyncFuture.invokeCallback(AbstractAsyncFuture.java:217) at com.ibm.io.async.AsyncChannelFuture$1.run(AsyncChannelFuture.java:205) at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1469) Caused by: java.lang.reflect.InvocationTargetException at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:67) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:521) at org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:246) ... 29 more Caused by: java.lang.RuntimeException: XPathFactory#newInstance() failed to create an XPathFactory for the default object model: http://java.sun.com/jaxp/xpath/dom with the XPathFactoryConfigurationException: javax.xml.xpath.XPathFactoryConfigurationException: No XPathFctory
[jira] Commented: (TUSCANY-2200) Sample calculator-webapp fails in WAS 6.1
[ https://issues.apache.org/jira/browse/TUSCANY-2200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12586040#action_12586040 ] Jean-Sebastien Delfino commented on TUSCANY-2200: - Actually not in lib/ext, it's in the WAS lib directory: xalan-2.7.0.jar So I'm not sure I understand why we'd need to add it again as a dependency of the Webapp... Sample calculator-webapp fails in WAS 6.1 - Key: TUSCANY-2200 URL: https://issues.apache.org/jira/browse/TUSCANY-2200 Project: Tuscany Issue Type: Bug Components: Java SCA Samples Affects Versions: Java-SCA-1.2 Reporter: Luciano Resende Fix For: Java-SCA-1.2 Exception = org.osoa.sca.ServiceRuntimeException Source = com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.init probeid = 111 Stack Dump = org.osoa.sca.ServiceRuntimeException: java.lang.reflect.InvocationTargetException at org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:264) at org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SCADomain.java:82) at org.apache.tuscany.sca.host.webapp.WebAppServletHost.init(WebAppServletHost.java:216) at org.apache.tuscany.sca.host.webapp.TuscanyServletFilter.init(TuscanyServletFilter.java:50) at com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.init(FilterInstanceWrapper.java:142) at com.ibm.ws.webcontainer.filter.WebAppFilterManager._loadFilter(WebAppFilterManager.java:465) at com.ibm.ws.webcontainer.filter.WebAppFilterManager.loadFilter(WebAppFilterManager.java:379) at com.ibm.ws.webcontainer.filter.WebAppFilterManager.getFilterInstanceWrapper(WebAppFilterManager.java:238) at com.ibm.ws.webcontainer.filter.WebAppFilterManager.getFilterChain(WebAppFilterManager.java:296) at com.ibm.ws.webcontainer.filter.WebAppFilterManager.doFilter(WebAppFilterManager.java:721) at com.ibm.ws.webcontainer.filter.WebAppFilterManager.doFilter(WebAppFilterManager.java:673) at com.ibm.ws.webcontainer.filter.WebAppFilterManager.invokeFilters(WebAppFilterManager.java:688) at com.ibm.ws.wswebcontainer.filter.WebAppFilterManager.invokeFilters(WebAppFilterManager.java:101) at com.ibm.ws.webcontainer.extension.DefaultExtensionProcessor.invokeFilters(DefaultExtensionProcessor.java:758) at com.ibm.ws.webcontainer.extension.DefaultExtensionProcessor.handleRequest(DefaultExtensionProcessor.java:471) at com.ibm.ws.wswebcontainer.extension.DefaultExtensionProcessor.handleRequest(DefaultExtensionProcessor.java:113) at com.ibm.ws.webcontainer.webapp.WebApp.handleRequest(WebApp.java:3276) at com.ibm.ws.webcontainer.webapp.WebGroup.handleRequest(WebGroup.java:267) at com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:811) at com.ibm.ws.wswebcontainer.WebContainer.handleRequest(WebContainer.java:1455) at com.ibm.ws.webcontainer.channel.WCChannelLink.ready(WCChannelLink.java:113) at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleDiscrimination(HttpInboundLink.java:454) at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleNewInformation(HttpInboundLink.java:383) at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.ready(HttpInboundLink.java:263) at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.sendToDiscriminators(NewConnectionInitialReadCallback.java:214) at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.complete(NewConnectionInitialReadCallback.java:113) at com.ibm.ws.tcp.channel.impl.AioReadCompletionListener.futureCompleted(AioReadCompletionListener.java:165) at com.ibm.io.async.AbstractAsyncFuture.invokeCallback(AbstractAsyncFuture.java:217) at com.ibm.io.async.AsyncChannelFuture$1.run(AsyncChannelFuture.java:205) at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1469) Caused by: java.lang.reflect.InvocationTargetException at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:67) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:521) at org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:246) ... 29 more Caused by: java.lang.RuntimeException: XPathFactory#newInstance() failed to create an XPathFactory for the default object model: http://java.sun.com/jaxp/xpath/dom with the XPathFactoryConfigurationException: javax.xml.xpath.XPathFactoryConfigurationException: No XPathFctory
[jira] Commented: (TUSCANY-2202) Sample feed-aggregator fails in WAS 6.1
[ https://issues.apache.org/jira/browse/TUSCANY-2202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12585833#action_12585833 ] Jean-Sebastien Delfino commented on TUSCANY-2202: - the link is to rssAggregator is: http://localhost:8080/sample-feed-aggregator-webapp/rssAggregator How did you install the app? did you name it sample-feed-aggregator-webapp? Maybe we can also make the link in index.html relative so that it still works if you name the app differently. Sample feed-aggregator fails in WAS 6.1 --- Key: TUSCANY-2202 URL: https://issues.apache.org/jira/browse/TUSCANY-2202 Project: Tuscany Issue Type: Bug Components: Java SCA Samples Affects Versions: Java-SCA-1.2 Reporter: Luciano Resende Fix For: Java-SCA-1.2 Start the application and click on one of the links Error 404: SRVE0190E: File not found: /rssAggregator -- 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] Commented: (TUSCANY-2200) Sample calculator-webapp fails in WAS 6.1
[ https://issues.apache.org/jira/browse/TUSCANY-2200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12585837#action_12585837 ] Jean-Sebastien Delfino commented on TUSCANY-2200: - The problem is that line in CompositeProcessor (line 82): // FIXME: to be refactored private XPathFactory xPathFactory = XPathFactory.newInstance(); Well the FIXME comment is right to the point :) We shouldn't initialize an xPathFactory statically here as it'll require an XPath implementation on the classpath (from Xalan for example) to work. It's really not good to have that static dependency on a 2Mb JAR just for handling xpath expressions in SCDL property source expressions (see CompositeProcessor line 262 for some code that uses that xPathFactory). We should only require an XPath factory when we really need to process XPath expressions. So - yeah - the FIXME comment at the top is right, this should be refactored cleaned up would be a better way to characterize it. Sample calculator-webapp fails in WAS 6.1 - Key: TUSCANY-2200 URL: https://issues.apache.org/jira/browse/TUSCANY-2200 Project: Tuscany Issue Type: Bug Components: Java SCA Samples Affects Versions: Java-SCA-1.2 Reporter: Luciano Resende Fix For: Java-SCA-1.2 Exception = org.osoa.sca.ServiceRuntimeException Source = com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.init probeid = 111 Stack Dump = org.osoa.sca.ServiceRuntimeException: java.lang.reflect.InvocationTargetException at org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:264) at org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SCADomain.java:82) at org.apache.tuscany.sca.host.webapp.WebAppServletHost.init(WebAppServletHost.java:216) at org.apache.tuscany.sca.host.webapp.TuscanyServletFilter.init(TuscanyServletFilter.java:50) at com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.init(FilterInstanceWrapper.java:142) at com.ibm.ws.webcontainer.filter.WebAppFilterManager._loadFilter(WebAppFilterManager.java:465) at com.ibm.ws.webcontainer.filter.WebAppFilterManager.loadFilter(WebAppFilterManager.java:379) at com.ibm.ws.webcontainer.filter.WebAppFilterManager.getFilterInstanceWrapper(WebAppFilterManager.java:238) at com.ibm.ws.webcontainer.filter.WebAppFilterManager.getFilterChain(WebAppFilterManager.java:296) at com.ibm.ws.webcontainer.filter.WebAppFilterManager.doFilter(WebAppFilterManager.java:721) at com.ibm.ws.webcontainer.filter.WebAppFilterManager.doFilter(WebAppFilterManager.java:673) at com.ibm.ws.webcontainer.filter.WebAppFilterManager.invokeFilters(WebAppFilterManager.java:688) at com.ibm.ws.wswebcontainer.filter.WebAppFilterManager.invokeFilters(WebAppFilterManager.java:101) at com.ibm.ws.webcontainer.extension.DefaultExtensionProcessor.invokeFilters(DefaultExtensionProcessor.java:758) at com.ibm.ws.webcontainer.extension.DefaultExtensionProcessor.handleRequest(DefaultExtensionProcessor.java:471) at com.ibm.ws.wswebcontainer.extension.DefaultExtensionProcessor.handleRequest(DefaultExtensionProcessor.java:113) at com.ibm.ws.webcontainer.webapp.WebApp.handleRequest(WebApp.java:3276) at com.ibm.ws.webcontainer.webapp.WebGroup.handleRequest(WebGroup.java:267) at com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:811) at com.ibm.ws.wswebcontainer.WebContainer.handleRequest(WebContainer.java:1455) at com.ibm.ws.webcontainer.channel.WCChannelLink.ready(WCChannelLink.java:113) at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleDiscrimination(HttpInboundLink.java:454) at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleNewInformation(HttpInboundLink.java:383) at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.ready(HttpInboundLink.java:263) at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.sendToDiscriminators(NewConnectionInitialReadCallback.java:214) at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.complete(NewConnectionInitialReadCallback.java:113) at com.ibm.ws.tcp.channel.impl.AioReadCompletionListener.futureCompleted(AioReadCompletionListener.java:165) at com.ibm.io.async.AbstractAsyncFuture.invokeCallback(AbstractAsyncFuture.java:217) at com.ibm.io.async.AsyncChannelFuture$1.run(AsyncChannelFuture.java:205) at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1469) Caused by: java.lang.reflect.InvocationTargetException at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at
[jira] Resolved: (TUSCANY-2182) ClassLoader issues with node2 launcher on WebSphere
[ https://issues.apache.org/jira/browse/TUSCANY-2182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino resolved TUSCANY-2182. - Resolution: Fixed Resolved - finally... - in SVN revisions r644201 (trunk) and r644202 (1.2 branch) ClassLoader issues with node2 launcher on WebSphere --- Key: TUSCANY-2182 URL: https://issues.apache.org/jira/browse/TUSCANY-2182 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-1.2 Reporter: Jean-Sebastien Delfino Assignee: Jean-Sebastien Delfino Fix For: Java-SCA-1.2 The classloader used by Node2 uses a parent-first loading scheme which does not work on WebSphere application server, as different versions of the Tuscany runtime dependencies are on the classpath of Webapps in the WebSphere environment. The fix for that issue is simply to ensure that the Node2 launcher uses a parent-last classloading scheme to load its runtime classes. -- 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] Resolved: (TUSCANY-2181) Minor fixes to samples README and .html files
[ https://issues.apache.org/jira/browse/TUSCANY-2181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino resolved TUSCANY-2181. - Resolution: Fixed Minor fixes to samples README and .html files - Key: TUSCANY-2181 URL: https://issues.apache.org/jira/browse/TUSCANY-2181 Project: Tuscany Issue Type: Bug Components: Java SCA Samples Affects Versions: Java-SCA-1.2 Reporter: Jean-Sebastien Delfino Assignee: Jean-Sebastien Delfino Priority: Minor Fix For: Java-SCA-1.2 While reviewing the 1.2 samples, I'm seeing typos and minor issues with the README and some of the .html files. I'll fix the ones I see carefully as I go through them. I'll make the fixes in both trunk and the 1.2 branch. -- 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] Commented: (TUSCANY-2183) Sample Catalog JSP does not compile on WebSphere App Server
[ https://issues.apache.org/jira/browse/TUSCANY-2183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12584435#action_12584435 ] Jean-Sebastien Delfino commented on TUSCANY-2183: - I've committed a fix to trunk in SVN revision r643759, it's a very small risk-free change, I'd like to merge it into the 1.2 branch. Sample Catalog JSP does not compile on WebSphere App Server --- Key: TUSCANY-2183 URL: https://issues.apache.org/jira/browse/TUSCANY-2183 Project: Tuscany Issue Type: Bug Components: Java SCA Samples Affects Versions: Java-SCA-1.2 Reporter: Jean-Sebastien Delfino Assignee: Jean-Sebastien Delfino Fix For: Java-SCA-1.2 tutorial/catalog-webapp/webapp/catalog.jsp uses a (for x: collection) construct which is not supported by the WebSphere JSP compiler in its default configuration. Changing to for (i = 0; i n; i++) fixes the JSP compile error. -- 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] Commented: (TUSCANY-2183) Sample Catalog JSP does not compile on WebSphere App Server
[ https://issues.apache.org/jira/browse/TUSCANY-2183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12584477#action_12584477 ] Jean-Sebastien Delfino commented on TUSCANY-2183: - Done in SVN r643811. Sample Catalog JSP does not compile on WebSphere App Server --- Key: TUSCANY-2183 URL: https://issues.apache.org/jira/browse/TUSCANY-2183 Project: Tuscany Issue Type: Bug Components: Java SCA Samples Affects Versions: Java-SCA-1.2 Reporter: Jean-Sebastien Delfino Assignee: Jean-Sebastien Delfino Fix For: Java-SCA-1.2 tutorial/catalog-webapp/webapp/catalog.jsp uses a (for x: collection) construct which is not supported by the WebSphere JSP compiler in its default configuration. Changing to for (i = 0; i n; i++) fixes the JSP compile error. -- 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] Resolved: (TUSCANY-2183) Sample Catalog JSP does not compile on WebSphere App Server
[ https://issues.apache.org/jira/browse/TUSCANY-2183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino resolved TUSCANY-2183. - Resolution: Fixed Sample Catalog JSP does not compile on WebSphere App Server --- Key: TUSCANY-2183 URL: https://issues.apache.org/jira/browse/TUSCANY-2183 Project: Tuscany Issue Type: Bug Components: Java SCA Samples Affects Versions: Java-SCA-1.2 Reporter: Jean-Sebastien Delfino Assignee: Jean-Sebastien Delfino Fix For: Java-SCA-1.2 tutorial/catalog-webapp/webapp/catalog.jsp uses a (for x: collection) construct which is not supported by the WebSphere JSP compiler in its default configuration. Changing to for (i = 0; i n; i++) fixes the JSP compile error. -- 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] Commented: (TUSCANY-2182) ClassLoader issues with node2 launcher on WebSphere
[ https://issues.apache.org/jira/browse/TUSCANY-2182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12584481#action_12584481 ] Jean-Sebastien Delfino commented on TUSCANY-2182: - I have fixed the classloader issues and committed the fix to trunk under SVN revision r643814 but need to to more testing before porting the fix to the 1.2 branch. In particular I'm seeing issues with ServletFilters on WebSphere App Server 6.1. The call to FilterChain.doFilter() in the Tuscany servlet filter seems to return before the target application servlet is invoked, so the classloader set on the thread context by the filter gets reset before the application code executes (and that code then executes with an incorrect class loading context). I'm investigating... and will update here as soon as I understand what's going on with these servlet filters. ClassLoader issues with node2 launcher on WebSphere --- Key: TUSCANY-2182 URL: https://issues.apache.org/jira/browse/TUSCANY-2182 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-1.2 Reporter: Jean-Sebastien Delfino Assignee: Jean-Sebastien Delfino Fix For: Java-SCA-1.2 The classloader used by Node2 uses a parent-first loading scheme which does not work on WebSphere application server, as different versions of the Tuscany runtime dependencies are on the classpath of Webapps in the WebSphere environment. The fix for that issue is simply to ensure that the Node2 launcher uses a parent-last classloading scheme to load its runtime classes. -- 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] Commented: (TUSCANY-2167) Cleanup SCA Sample dependencies
[ https://issues.apache.org/jira/browse/TUSCANY-2167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12584757#action_12584757 ] Jean-Sebastien Delfino commented on TUSCANY-2167: - I've reviewed the diffs in the patch and it looks OK to me, but I can't really test it thoroughly as the patch does not apply correctly to my source tree, generating a lot of Reversed (or previously applied) patch detected! messages and rejects. I didn't realize that initially, and only realized it after seeing build errors caused by the missing or mis-applied changes. I'd suggest to apply your changes to the branch if they don't break the build for you. Cleanup SCA Sample dependencies --- Key: TUSCANY-2167 URL: https://issues.apache.org/jira/browse/TUSCANY-2167 Project: Tuscany Issue Type: Bug Affects Versions: Java-SCA-1.2 Reporter: Luciano Resende Assignee: Luciano Resende Fix For: Java-SCA-1.2 Attachments: TUSCANY-2167.patch http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg29677.html -- 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] Created: (TUSCANY-2178) Deleting a node throws Javascript error in admin
Deleting a node throws Javascript error in admin Key: TUSCANY-2178 URL: https://issues.apache.org/jira/browse/TUSCANY-2178 Project: Tuscany Issue Type: Bug Components: Java SCA Domain Management Affects Versions: Java-SCA-1.2 Reporter: Jean-Sebastien Delfino Assignee: Jean-Sebastien Delfino Fix For: Java-SCA-1.2 Deleting a node in the admin console does not work and throws a Javascript error. That's a timing issue as the admin sends two AJAX requests to first stop the node and then delete it, but in most cases the delete call jumps the line and gets invoked before the stop, causing the stop action to fail. A simple fix is to invoke these two steps from the server side. -- 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] Created: (TUSCANY-2179) Plugin installation from update site does not say 1.2-incubating
Plugin installation from update site does not say 1.2-incubating Key: TUSCANY-2179 URL: https://issues.apache.org/jira/browse/TUSCANY-2179 Project: Tuscany Issue Type: Bug Components: Build System Affects Versions: Java-SCA-1.2 Reporter: Jean-Sebastien Delfino Assignee: Jean-Sebastien Delfino Fix For: Java-SCA-1.2 The plugin update site references the Tuscany bin distribution (installed as part of the plugin install) as runtime.jar, causing the install dialog to just say 'runtime.jar' instead of 'apache-tuscany-1.2-incubating'. -- 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] Resolved: (TUSCANY-2175) Plugin does not properly log errors and release its progress monitor
[ https://issues.apache.org/jira/browse/TUSCANY-2175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino resolved TUSCANY-2175. - Resolution: Fixed Plugin does not properly log errors and release its progress monitor Key: TUSCANY-2175 URL: https://issues.apache.org/jira/browse/TUSCANY-2175 Project: Tuscany Issue Type: Bug Components: Java SCA Tools Affects Versions: Java-SCA-1.2 Reporter: Jean-Sebastien Delfino Assignee: Jean-Sebastien Delfino Fix For: Java-SCA-1.2 That makes it really difficult to investigate errors or even know when it has finished launching a composite. The fix is a simple risk free fix, add calls to log errors and release the progress monitor in a finally block. -- 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] Created: (TUSCANY-2181) Minor fixes to samples README and .html files
Minor fixes to samples README and .html files - Key: TUSCANY-2181 URL: https://issues.apache.org/jira/browse/TUSCANY-2181 Project: Tuscany Issue Type: Bug Components: Java SCA Samples Affects Versions: Java-SCA-1.2 Reporter: Jean-Sebastien Delfino Assignee: Jean-Sebastien Delfino Priority: Minor Fix For: Java-SCA-1.2 While reviewing the 1.2 samples, I'm seeing typos and minor issues with the README and some of the .html files. I'll fix the ones I see carefully as I go through them. I'll make the fixes in both trunk and the 1.2 branch. -- 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] Resolved: (TUSCANY-2179) Plugin installation from update site does not say 1.2-incubating
[ https://issues.apache.org/jira/browse/TUSCANY-2179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino resolved TUSCANY-2179. - Resolution: Fixed Fixed in trunk and 1.2 branch. Plugin installation from update site does not say 1.2-incubating Key: TUSCANY-2179 URL: https://issues.apache.org/jira/browse/TUSCANY-2179 Project: Tuscany Issue Type: Bug Components: Build System Affects Versions: Java-SCA-1.2 Reporter: Jean-Sebastien Delfino Assignee: Jean-Sebastien Delfino Fix For: Java-SCA-1.2 The plugin update site references the Tuscany bin distribution (installed as part of the plugin install) as runtime.jar, causing the install dialog to just say 'runtime.jar' instead of 'apache-tuscany-1.2-incubating'. -- 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] Resolved: (TUSCANY-2178) Deleting a node throws Javascript error in admin
[ https://issues.apache.org/jira/browse/TUSCANY-2178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino resolved TUSCANY-2178. - Resolution: Fixed Deleting a node throws Javascript error in admin Key: TUSCANY-2178 URL: https://issues.apache.org/jira/browse/TUSCANY-2178 Project: Tuscany Issue Type: Bug Components: Java SCA Domain Management Affects Versions: Java-SCA-1.2 Reporter: Jean-Sebastien Delfino Assignee: Jean-Sebastien Delfino Fix For: Java-SCA-1.2 Deleting a node in the admin console does not work and throws a Javascript error. That's a timing issue as the admin sends two AJAX requests to first stop the node and then delete it, but in most cases the delete call jumps the line and gets invoked before the stop, causing the stop action to fail. A simple fix is to invoke these two steps from the server side. -- 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] Created: (TUSCANY-2182) ClassLoader issues with node2 launcher on WebSphere
ClassLoader issues with node2 launcher on WebSphere --- Key: TUSCANY-2182 URL: https://issues.apache.org/jira/browse/TUSCANY-2182 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-1.2 Reporter: Jean-Sebastien Delfino Assignee: Jean-Sebastien Delfino Fix For: Java-SCA-1.2 The classloader used by Node2 uses a parent-first loading scheme which does not work on WebSphere application server, as different versions of the Tuscany runtime dependencies are on the classpath of Webapps in the WebSphere environment. The fix for that issue is simply to ensure that the Node2 launcher uses a parent-last classloading scheme to load its runtime classes. -- 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] Commented: (TUSCANY-2182) ClassLoader issues with node2 launcher on WebSphere
[ https://issues.apache.org/jira/browse/TUSCANY-2182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12584412#action_12584412 ] Jean-Sebastien Delfino commented on TUSCANY-2182: - Also, when running on WebSphere, some of the URLClassLoaders in the classloader hierarchy have getURLs() return null, causing an NPE in NodeImpl. The fix is just to add a test for nulls. ClassLoader issues with node2 launcher on WebSphere --- Key: TUSCANY-2182 URL: https://issues.apache.org/jira/browse/TUSCANY-2182 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-1.2 Reporter: Jean-Sebastien Delfino Assignee: Jean-Sebastien Delfino Fix For: Java-SCA-1.2 The classloader used by Node2 uses a parent-first loading scheme which does not work on WebSphere application server, as different versions of the Tuscany runtime dependencies are on the classpath of Webapps in the WebSphere environment. The fix for that issue is simply to ensure that the Node2 launcher uses a parent-last classloading scheme to load its runtime classes. -- 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] Created: (TUSCANY-2183) Sample Catalog JSP does not compile on WebSphere App Server
Sample Catalog JSP does not compile on WebSphere App Server --- Key: TUSCANY-2183 URL: https://issues.apache.org/jira/browse/TUSCANY-2183 Project: Tuscany Issue Type: Bug Components: Java SCA Samples Affects Versions: Java-SCA-1.2 Reporter: Jean-Sebastien Delfino Assignee: Jean-Sebastien Delfino Fix For: Java-SCA-1.2 tutorial/catalog-webapp/webapp/catalog.jsp uses a (for x: collection) construct which is not supported by the WebSphere JSP compiler in its default configuration. Changing to for (i = 0; i n; i++) fixes the JSP compile error. -- 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] Commented: (TUSCANY-2166) Tuscany eclipse library buildpath exceeds max Windows command line length
[ https://issues.apache.org/jira/browse/TUSCANY-2166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12583555#action_12583555 ] Jean-Sebastien Delfino commented on TUSCANY-2166: - For this to work, I need to make a small change to the node launcher to allow test programs for example to get an SCA node from the launcher instead of creating the SCA node directly (as creating the SCA node directly would again require all the runtime JARs to be on their Eclipse buildpath or runtime classpath). Tuscany eclipse library buildpath exceeds max Windows command line length - Key: TUSCANY-2166 URL: https://issues.apache.org/jira/browse/TUSCANY-2166 Project: Tuscany Issue Type: Bug Components: Java SCA Tools Affects Versions: Java-SCA-1.2 Reporter: Jean-Sebastien Delfino Assignee: Jean-Sebastien Delfino Fix For: Java-SCA-1.2 Adding the Tuscany library from the Tuscany Eclipse plugin to a Java project breaks it as its buildpath exceeds the limit of the Windows command line length, preventing any programs to be launched from that project. The fix is pretty simple, all the runtime JARs configured in the Tuscany library should not be there anyway. Only the API JARs and the node launcher JAR need to be on the buildpath. -- 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] Created: (TUSCANY-2168) Incorrect level of commons-httpclient in distribution
Incorrect level of commons-httpclient in distribution - Key: TUSCANY-2168 URL: https://issues.apache.org/jira/browse/TUSCANY-2168 Project: Tuscany Issue Type: Bug Components: Build System Affects Versions: Java-SCA-1.2 Reporter: Jean-Sebastien Delfino Priority: Critical Fix For: Java-SCA-1.2 When I build the distribution I get commons-httpclient-2.0.1 in the distro lib. The bindings that use that the httpclient require commons-httpclient-3.0.1 and fail with various exceptions like ClassNotFound and NoSuchMethod. -- 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] Resolved: (TUSCANY-2166) Tuscany eclipse library buildpath exceeds max Windows command line length
[ https://issues.apache.org/jira/browse/TUSCANY-2166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino resolved TUSCANY-2166. - Resolution: Fixed Fixed in SVN revision 642941. Eclipse projects now only have the API and launcher JARs on their buildpath. Tuscany eclipse library buildpath exceeds max Windows command line length - Key: TUSCANY-2166 URL: https://issues.apache.org/jira/browse/TUSCANY-2166 Project: Tuscany Issue Type: Bug Components: Java SCA Tools Affects Versions: Java-SCA-1.2 Reporter: Jean-Sebastien Delfino Assignee: Jean-Sebastien Delfino Fix For: Java-SCA-1.2 Adding the Tuscany library from the Tuscany Eclipse plugin to a Java project breaks it as its buildpath exceeds the limit of the Windows command line length, preventing any programs to be launched from that project. The fix is pretty simple, all the runtime JARs configured in the Tuscany library should not be there anyway. Only the API JARs and the node launcher JAR need to be on the buildpath. -- 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] Commented: (TUSCANY-2171) binding.sca bindingType in definitions.xml not used if SCA binding is created during build phase
[
https://issues.apache.org/jira/browse/TUSCANY-2171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12583772#action_12583772
]
Jean-Sebastien Delfino commented on TUSCANY-2171:
-
A simpler fix is to pass the Definitions model object to the builder and then
look for the BindingType of the SCABinding in that Definitions object.
There is no need to create a proxy to an unresolved BindingType model object
and then try to resolve it later in your scenario. That kind of deferred
resolution is only relevant at read time when the SCA artifacts being read are
presented in a random order and you need to defer the resolution of references
to objects that have not been read yet...
In your case here, everything including BindingTypes has been read way before,
you just need to pass that Definitions model to the builder so that it can get
the correct BindingType for the SCABinding from it and point to it.
Hope this helps.
binding.sca bindingType in definitions.xml not used if SCA binding is created
during build phase
Key: TUSCANY-2171
URL: https://issues.apache.org/jira/browse/TUSCANY-2171
Project: Tuscany
Issue Type: Bug
Components: Java SCA Core Runtime
Affects Versions: Java-SCA-1.0.1
Reporter: Greg Dritschler
Assignee: Venkatakrishnan
I have a definitions.xml file which defines a bindingType for binding.sca.
bindingType type=sca:binding.sca mayProvide=propagatesTransaction/
I have a composite which uses an intent on a reference.
reference name=daService target=DataAccessComponent
requires=propagatesTransaction/
The reference does not have a binding.sca element. In this case the
binding model object is created by
CompositeConfigurationBuilderImpl.createSCABinding() which is shown below.
private SCABinding createSCABinding() {
SCABinding scaBinding = scaBindingFactory.createSCABinding();
IntentAttachPointType bindingType =
intentAttachPointTypeFactory.createBindingType();
bindingType.setName(BINDING_SCA_QNAME);
bindingType.setUnresolved(true);
((PolicySetAttachPoint)scaBinding).setType(bindingType);
return scaBinding;
}
This method creates an IntentAttachPointType which is unresolved. There is
no code to resolve the IntentAttachPointType to the real one. As a result
the PolicyComputer uses the unresolved IntentAttachPointType model and does
not realize that binding.sca provides the intent needed by the reference.
Discussed on tuscany-dev here:
http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg28903.html
--
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] Created: (TUSCANY-2175) Plugin does properly log errors and release its progress monitor
Plugin does properly log errors and release its progress monitor Key: TUSCANY-2175 URL: https://issues.apache.org/jira/browse/TUSCANY-2175 Project: Tuscany Issue Type: Bug Components: Java SCA Tools Affects Versions: Java-SCA-1.2 Reporter: Jean-Sebastien Delfino Assignee: Jean-Sebastien Delfino Fix For: Java-SCA-1.2 That makes it really difficult to investigate errors or even know when it has finished launching a composite. The fix is a simple risk free fix, add calls to log errors and release the progress monitor in a finally block. -- 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] Commented: (TUSCANY-2175) Plugin does properly log errors and release its progress monitor
[ https://issues.apache.org/jira/browse/TUSCANY-2175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12583883#action_12583883 ] Jean-Sebastien Delfino commented on TUSCANY-2175: - I committed fixes for annoying issues with the plugin (TUSCANY-2175) in trunk SVN revision 643158. It's a no risk fix so I'd like to merge it into the 1.2 branch if possible. Plugin does properly log errors and release its progress monitor Key: TUSCANY-2175 URL: https://issues.apache.org/jira/browse/TUSCANY-2175 Project: Tuscany Issue Type: Bug Components: Java SCA Tools Affects Versions: Java-SCA-1.2 Reporter: Jean-Sebastien Delfino Assignee: Jean-Sebastien Delfino Fix For: Java-SCA-1.2 That makes it really difficult to investigate errors or even know when it has finished launching a composite. The fix is a simple risk free fix, add calls to log errors and release the progress monitor in a finally block. -- 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-2175) Plugin does not properly log errors and release its progress monitor
[ https://issues.apache.org/jira/browse/TUSCANY-2175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino updated TUSCANY-2175: Summary: Plugin does not properly log errors and release its progress monitor (was: Plugin does properly log errors and release its progress monitor) Plugin does not properly log errors and release its progress monitor Key: TUSCANY-2175 URL: https://issues.apache.org/jira/browse/TUSCANY-2175 Project: Tuscany Issue Type: Bug Components: Java SCA Tools Affects Versions: Java-SCA-1.2 Reporter: Jean-Sebastien Delfino Assignee: Jean-Sebastien Delfino Fix For: Java-SCA-1.2 That makes it really difficult to investigate errors or even know when it has finished launching a composite. The fix is a simple risk free fix, add calls to log errors and release the progress monitor in a finally block. -- 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] Created: (TUSCANY-2176) implementation-ejb JARs missing from assembly
implementation-ejb JARs missing from assembly - Key: TUSCANY-2176 URL: https://issues.apache.org/jira/browse/TUSCANY-2176 Project: Tuscany Issue Type: Bug Components: Build System Affects Versions: Java-SCA-1.2 Reporter: Jean-Sebastien Delfino Assignee: Jean-Sebastien Delfino Fix For: Java-SCA-1.2 The implementation-ejb and implementation-ejb modules are missing from the distro assembly, preventing the EJB part of the tutorial to work (and actually causing more issues in it as that breaks some wires and the domain admin does not tolerate that kind of errors very well at the moment). -- 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] Created: (TUSCANY-2177) Incorrect dependencies in tutorial not reported by admin
Incorrect dependencies in tutorial not reported by admin - Key: TUSCANY-2177 URL: https://issues.apache.org/jira/browse/TUSCANY-2177 Project: Tuscany Issue Type: Bug Components: Java SCA Domain Management Affects Versions: Java-SCA-1.2 Reporter: Jean-Sebastien Delfino Assignee: Jean-Sebastien Delfino Priority: Minor Fix For: Java-SCA-1.2 The tutorial/assets module currently has incorrect dependency imports. These dependency errors are not correctly reported by the domain admin. The fix is very minor and risk free: - remove the incorrect imports from tutorial/assets/META-INF/sca-contribution.xml - display dependency problems on the admin contributions page (the logic was all there to get the list of problems but they were just not displayed) I'll try to get the fix in the 1.2 release as it's really useful to see contribution dependency errors. -- 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] Resolved: (TUSCANY-2177) Incorrect dependencies in tutorial not reported by admin
[ https://issues.apache.org/jira/browse/TUSCANY-2177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino resolved TUSCANY-2177. - Resolution: Fixed Incorrect dependencies in tutorial not reported by admin - Key: TUSCANY-2177 URL: https://issues.apache.org/jira/browse/TUSCANY-2177 Project: Tuscany Issue Type: Bug Components: Java SCA Domain Management Affects Versions: Java-SCA-1.2 Reporter: Jean-Sebastien Delfino Assignee: Jean-Sebastien Delfino Priority: Minor Fix For: Java-SCA-1.2 The tutorial/assets module currently has incorrect dependency imports. These dependency errors are not correctly reported by the domain admin. The fix is very minor and risk free: - remove the incorrect imports from tutorial/assets/META-INF/sca-contribution.xml - display dependency problems on the admin contributions page (the logic was all there to get the list of problems but they were just not displayed) I'll try to get the fix in the 1.2 release as it's really useful to see contribution dependency errors. -- 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] Resolved: (TUSCANY-2176) implementation-ejb JARs missing from assembly
[ https://issues.apache.org/jira/browse/TUSCANY-2176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino resolved TUSCANY-2176. - Resolution: Fixed implementation-ejb JARs missing from assembly - Key: TUSCANY-2176 URL: https://issues.apache.org/jira/browse/TUSCANY-2176 Project: Tuscany Issue Type: Bug Components: Build System Affects Versions: Java-SCA-1.2 Reporter: Jean-Sebastien Delfino Assignee: Jean-Sebastien Delfino Fix For: Java-SCA-1.2 The implementation-ejb and implementation-ejb modules are missing from the distro assembly, preventing the EJB part of the tutorial to work (and actually causing more issues in it as that breaks some wires and the domain admin does not tolerate that kind of errors very well at the moment). -- 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] Created: (TUSCANY-2166) Tuscany eclipse library buildpath exceeds max Windows command line length
Tuscany eclipse library buildpath exceeds max Windows command line length - Key: TUSCANY-2166 URL: https://issues.apache.org/jira/browse/TUSCANY-2166 Project: Tuscany Issue Type: Bug Components: Java SCA Tools Affects Versions: Java-SCA-1.2 Reporter: Jean-Sebastien Delfino Assignee: Jean-Sebastien Delfino Fix For: Java-SCA-1.2 Adding the Tuscany library from the Tuscany Eclipse plugin to a Java project breaks it as its buildpath exceeds the limit of the Windows command line length, preventing any programs to be launched from that project. The fix is pretty simple, all the runtime JARs configured in the Tuscany library should not be there anyway. Only the API JARs and the node launcher JAR need to be on the buildpath. -- 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] Assigned: (TUSCANY-2163) Marketplace Store for Tutorial
[ https://issues.apache.org/jira/browse/TUSCANY-2163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino reassigned TUSCANY-2163: --- Assignee: Jean-Sebastien Delfino Marketplace Store for Tutorial -- Key: TUSCANY-2163 URL: https://issues.apache.org/jira/browse/TUSCANY-2163 Project: Tuscany Issue Type: New Feature Components: Java SCA Samples Reporter: Mario Antollini Assignee: Jean-Sebastien Delfino Priority: Minor Attachments: store-market.zip I have created new module for the tutorial and called it store-market. As Jean-Sebastien suggested I took store-merger and modified it. I now need to start working on the multiplicity 0..n instead of the currently hardcoded references to two catalogs. -- 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] Commented: (TUSCANY-2166) Tuscany eclipse library buildpath exceeds max Windows command line length
[ https://issues.apache.org/jira/browse/TUSCANY-2166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12583547#action_12583547 ] Jean-Sebastien Delfino commented on TUSCANY-2166: - I'm working on it and will try to get it in before the next RC is cut. Tuscany eclipse library buildpath exceeds max Windows command line length - Key: TUSCANY-2166 URL: https://issues.apache.org/jira/browse/TUSCANY-2166 Project: Tuscany Issue Type: Bug Components: Java SCA Tools Affects Versions: Java-SCA-1.2 Reporter: Jean-Sebastien Delfino Assignee: Jean-Sebastien Delfino Fix For: Java-SCA-1.2 Adding the Tuscany library from the Tuscany Eclipse plugin to a Java project breaks it as its buildpath exceeds the limit of the Windows command line length, preventing any programs to be launched from that project. The fix is pretty simple, all the runtime JARs configured in the Tuscany library should not be there anyway. Only the API JARs and the node launcher JAR need to be on the buildpath. -- 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] Commented: (TUSCANY-2163) Marketplace Store for Tutorial
[ https://issues.apache.org/jira/browse/TUSCANY-2163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12583546#action_12583546 ] Jean-Sebastien Delfino commented on TUSCANY-2163: - Thanks Mario I will add that new module under /tutorial. Marketplace Store for Tutorial -- Key: TUSCANY-2163 URL: https://issues.apache.org/jira/browse/TUSCANY-2163 Project: Tuscany Issue Type: New Feature Components: Java SCA Samples Reporter: Mario Antollini Assignee: Jean-Sebastien Delfino Priority: Minor Attachments: store-market.zip I have created new module for the tutorial and called it store-market. As Jean-Sebastien suggested I took store-merger and modified it. I now need to start working on the multiplicity 0..n instead of the currently hardcoded references to two catalogs. -- 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-2163) Marketplace Store for Tutorial
[ https://issues.apache.org/jira/browse/TUSCANY-2163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino updated TUSCANY-2163: Patch Info: [Patch Available] Marketplace Store for Tutorial -- Key: TUSCANY-2163 URL: https://issues.apache.org/jira/browse/TUSCANY-2163 Project: Tuscany Issue Type: New Feature Components: Java SCA Samples Affects Versions: Java-SCA-Next Reporter: Mario Antollini Assignee: Jean-Sebastien Delfino Priority: Minor Fix For: Java-SCA-Next Attachments: store-market.zip I have created new module for the tutorial and called it store-market. As Jean-Sebastien suggested I took store-merger and modified it. I now need to start working on the multiplicity 0..n instead of the currently hardcoded references to two catalogs. -- 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-2163) Marketplace Store for Tutorial
[ https://issues.apache.org/jira/browse/TUSCANY-2163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino updated TUSCANY-2163: Affects Version/s: Java-SCA-Next Fix Version/s: Java-SCA-Next Marketplace Store for Tutorial -- Key: TUSCANY-2163 URL: https://issues.apache.org/jira/browse/TUSCANY-2163 Project: Tuscany Issue Type: New Feature Components: Java SCA Samples Affects Versions: Java-SCA-Next Reporter: Mario Antollini Assignee: Jean-Sebastien Delfino Priority: Minor Fix For: Java-SCA-Next Attachments: store-market.zip I have created new module for the tutorial and called it store-market. As Jean-Sebastien suggested I took store-merger and modified it. I now need to start working on the multiplicity 0..n instead of the currently hardcoded references to two catalogs. -- 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] Created: (TUSCANY-2157) Tuscany plugin Run As shortcut uses incorrect runtime launcher name
Tuscany plugin Run As shortcut uses incorrect runtime launcher name - Key: TUSCANY-2157 URL: https://issues.apache.org/jira/browse/TUSCANY-2157 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-1.2 Reporter: Jean-Sebastien Delfino Fix For: Java-SCA-1.2 The Tuscany plugin Run As shortcut uses an incorrect name for the runtime launcher class, causing a ClassNotFoundException when you click on Run As / Tuscany in Eclipse. -- 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] Assigned: (TUSCANY-2157) Tuscany plugin Run As shortcut uses incorrect runtime launcher name
[ https://issues.apache.org/jira/browse/TUSCANY-2157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino reassigned TUSCANY-2157: --- Assignee: Jean-Sebastien Delfino Tuscany plugin Run As shortcut uses incorrect runtime launcher name - Key: TUSCANY-2157 URL: https://issues.apache.org/jira/browse/TUSCANY-2157 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-1.2 Reporter: Jean-Sebastien Delfino Assignee: Jean-Sebastien Delfino Fix For: Java-SCA-1.2 The Tuscany plugin Run As shortcut uses an incorrect name for the runtime launcher class, causing a ClassNotFoundException when you click on Run As / Tuscany in Eclipse. -- 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] Created: (TUSCANY-2158) EJB remote interfaces should be considered @Remotable
EJB remote interfaces should be considered @Remotable - Key: TUSCANY-2158 URL: https://issues.apache.org/jira/browse/TUSCANY-2158 Project: Tuscany Issue Type: Bug Components: Java SCA EJB Binding Extension Affects Versions: Java-SCA-1.2 Reporter: Jean-Sebastien Delfino Assignee: Jean-Sebastien Delfino Fix For: Java-SCA-1.2 This is similar to what we are already doing for service interfaces annotated with @WebService. Service interfaces annotated with @Remote or extending javax.ejb.EJBObject or java.rmi.Remote should be considered remotable as well. Not considering them remotable currently forces the application developer to make a local copy of these interfaces and add the SCA @Remotable annotation to them. -- 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] Created: (TUSCANY-2159) EJB binding extension not using the correct EJB interface class loader
EJB binding extension not using the correct EJB interface class loader -- Key: TUSCANY-2159 URL: https://issues.apache.org/jira/browse/TUSCANY-2159 Project: Tuscany Issue Type: Bug Components: Java SCA EJB Binding Extension Affects Versions: Java-SCA-1.2 Reporter: Jean-Sebastien Delfino Assignee: Jean-Sebastien Delfino Fix For: Java-SCA-1.2 The EJB binding invoker seems to just rely on the classloader present on the current thread context to resolve EJB interface classes returned from a JNDI lookup of the EJB. This causes a ClassNotFoundException in the EJB interface specified on the reference is coming from another classloader than the current thread context classloader. This will likely cause similar issues with the EJB method parameter classes as well. A quick fix for release 1.2 is to set that classloader on the current thread context before calling the invoker's doInvoke method. A longer term fix will require more investigation. -- 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] Created: (TUSCANY-2160) Tutorial EJB module missing from the distribution
Tutorial EJB module missing from the distribution - Key: TUSCANY-2160 URL: https://issues.apache.org/jira/browse/TUSCANY-2160 Project: Tuscany Issue Type: Bug Components: Java SCA Samples Affects Versions: Java-SCA-1.2 Reporter: Jean-Sebastien Delfino Assignee: Jean-Sebastien Delfino Fix For: Java-SCA-1.2 The tutorial's EJB module (catalog-ejb) is missing from the distribution. If it can be made to work it should be included, as it covers a significant aspect of SCA/Tuscany: integration with EJB session beans. -- 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] Commented: (TUSCANY-2159) EJB binding extension not using the correct EJB interface class loader
[ https://issues.apache.org/jira/browse/TUSCANY-2159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12582709#action_12582709 ] Jean-Sebastien Delfino commented on TUSCANY-2159: - Committed the short term fix in the trunk and 1.2 branch. EJB binding extension not using the correct EJB interface class loader -- Key: TUSCANY-2159 URL: https://issues.apache.org/jira/browse/TUSCANY-2159 Project: Tuscany Issue Type: Bug Components: Java SCA EJB Binding Extension Affects Versions: Java-SCA-1.2 Reporter: Jean-Sebastien Delfino Assignee: Jean-Sebastien Delfino Fix For: Java-SCA-1.2 The EJB binding invoker seems to just rely on the classloader present on the current thread context to resolve EJB interface classes returned from a JNDI lookup of the EJB. This causes a ClassNotFoundException in the EJB interface specified on the reference is coming from another classloader than the current thread context classloader. This will likely cause similar issues with the EJB method parameter classes as well. A quick fix for release 1.2 is to set that classloader on the current thread context before calling the invoker's doInvoke method. A longer term fix will require more investigation. -- 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] Resolved: (TUSCANY-2143) Admin cannot display composites with references to unresolved classes
[ https://issues.apache.org/jira/browse/TUSCANY-2143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino resolved TUSCANY-2143. - Resolution: Fixed Admin cannot display composites with references to unresolved classes - Key: TUSCANY-2143 URL: https://issues.apache.org/jira/browse/TUSCANY-2143 Project: Tuscany Issue Type: Bug Affects Versions: Java-SCA-1.2 Reporter: Jean-Sebastien Delfino Assignee: Jean-Sebastien Delfino Fix For: Java-SCA-1.2 The domain admin currently fails to display a composite if it has references to unresolved classes, making it impossible to use at development/construction time where having unresolved classes is likely to happen. The fix is a simple fix to tolerate NoClassDefFoundErrors the same way we tolerate ClassNotFoundExceptions. -- 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] Resolved: (TUSCANY-2158) EJB remote interfaces should be considered @Remotable
[ https://issues.apache.org/jira/browse/TUSCANY-2158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino resolved TUSCANY-2158. - Resolution: Fixed EJB remote interfaces should be considered @Remotable - Key: TUSCANY-2158 URL: https://issues.apache.org/jira/browse/TUSCANY-2158 Project: Tuscany Issue Type: Bug Components: Java SCA EJB Binding Extension Affects Versions: Java-SCA-1.2 Reporter: Jean-Sebastien Delfino Assignee: Jean-Sebastien Delfino Fix For: Java-SCA-1.2 This is similar to what we are already doing for service interfaces annotated with @WebService. Service interfaces annotated with @Remote or extending javax.ejb.EJBObject or java.rmi.Remote should be considered remotable as well. Not considering them remotable currently forces the application developer to make a local copy of these interfaces and add the SCA @Remotable annotation to them. -- 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] Resolved: (TUSCANY-2159) EJB binding extension not using the correct EJB interface class loader
[ https://issues.apache.org/jira/browse/TUSCANY-2159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino resolved TUSCANY-2159. - Resolution: Fixed Actually this fix looks like the correct one, even for the longer term :) EJB binding extension not using the correct EJB interface class loader -- Key: TUSCANY-2159 URL: https://issues.apache.org/jira/browse/TUSCANY-2159 Project: Tuscany Issue Type: Bug Components: Java SCA EJB Binding Extension Affects Versions: Java-SCA-1.2 Reporter: Jean-Sebastien Delfino Assignee: Jean-Sebastien Delfino Fix For: Java-SCA-1.2 The EJB binding invoker seems to just rely on the classloader present on the current thread context to resolve EJB interface classes returned from a JNDI lookup of the EJB. This causes a ClassNotFoundException in the EJB interface specified on the reference is coming from another classloader than the current thread context classloader. This will likely cause similar issues with the EJB method parameter classes as well. A quick fix for release 1.2 is to set that classloader on the current thread context before calling the invoker's doInvoke method. A longer term fix will require more investigation. -- 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] Resolved: (TUSCANY-2157) Tuscany plugin Run As shortcut uses incorrect runtime launcher name
[ https://issues.apache.org/jira/browse/TUSCANY-2157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino resolved TUSCANY-2157. - Resolution: Fixed Tuscany plugin Run As shortcut uses incorrect runtime launcher name - Key: TUSCANY-2157 URL: https://issues.apache.org/jira/browse/TUSCANY-2157 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-1.2 Reporter: Jean-Sebastien Delfino Assignee: Jean-Sebastien Delfino Fix For: Java-SCA-1.2 The Tuscany plugin Run As shortcut uses an incorrect name for the runtime launcher class, causing a ClassNotFoundException when you click on Run As / Tuscany in Eclipse. -- 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] Created: (TUSCANY-2138) Contribution JARs should not be cached by URLConnections
Contribution JARs should not be cached by URLConnections Key: TUSCANY-2138 URL: https://issues.apache.org/jira/browse/TUSCANY-2138 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-1.2 Reporter: Jean-Sebastien Delfino Assignee: Jean-Sebastien Delfino Fix For: Java-SCA-1.2 Contribution JARs should not be cached by the URLConnections used to read them as caching these JARs makes updates impossible to handle without stopping/restarting the JVM. Code that uses URLConnections to read application contributions should call setUseCaches(false). Code that uses URL.openStream or ClassLoader.getResourceAsStream should be changed to use a URLConnection. -- 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] Resolved: (TUSCANY-2138) Contribution JARs should not be cached by URLConnections
[ https://issues.apache.org/jira/browse/TUSCANY-2138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino resolved TUSCANY-2138. - Resolution: Fixed Contribution JARs should not be cached by URLConnections Key: TUSCANY-2138 URL: https://issues.apache.org/jira/browse/TUSCANY-2138 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-1.2 Reporter: Jean-Sebastien Delfino Assignee: Jean-Sebastien Delfino Fix For: Java-SCA-1.2 Contribution JARs should not be cached by the URLConnections used to read them as caching these JARs makes updates impossible to handle without stopping/restarting the JVM. Code that uses URLConnections to read application contributions should call setUseCaches(false). Code that uses URL.openStream or ClassLoader.getResourceAsStream should be changed to use a URLConnection. -- 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] Created: (TUSCANY-2142) Reference to -SNAPSHOT breaking plugin's Tuscany classpath libary
Reference to -SNAPSHOT breaking plugin's Tuscany classpath libary - Key: TUSCANY-2142 URL: https://issues.apache.org/jira/browse/TUSCANY-2142 Project: Tuscany Issue Type: Bug Components: Build System Affects Versions: Java-SCA-1.2 Reporter: Jean-Sebastien Delfino Priority: Critical Fix For: Java-SCA-1.2 The 1.2 RC2 Tuscany Eclipse plugin still references Tuscany runtime and src distros named 1.2-incubating-SNAPSHOT instead of 1.2-incubating. This is breaking the Tuscany Library configuration in Eclipse, which ends up empty instead of containing all the Tuscany runtime JARs. There's a temporary workaround: - after having installed the Tuscany Eclipse feature from the update site, cd to eclipse/features/org.apache.tuscany.sca.feature_1.2.0 - rename runtime/tuscany-sca-1.2-incubating to runtime/tuscany-sca-1.2-incubating-SNAPSHOT - rename src/apache-tuscany-sca-1.2-incubating-src.zip to apache-tuscany-sca-1.2-incubating-SNAPSHOT-src.zip - after doing that, adding the Tuscany Library to a Java project should correctly add all the required JARs -- 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] Created: (TUSCANY-2143) Admin cannot display composites with references to unresolved classes
Admin cannot display composites with references to unresolved classes - Key: TUSCANY-2143 URL: https://issues.apache.org/jira/browse/TUSCANY-2143 Project: Tuscany Issue Type: Bug Affects Versions: Java-SCA-1.2 Reporter: Jean-Sebastien Delfino Assignee: Jean-Sebastien Delfino Fix For: Java-SCA-1.2 The domain admin currently fails to display a composite if it has references to unresolved classes, making it impossible to use at development/construction time where having unresolved classes is likely to happen. The fix is a simple fix to tolerate NoClassDefFoundErrors the same way we tolerate ClassNotFoundExceptions. -- 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] Assigned: (TUSCANY-2119) Eclipse plugin jars missing from the distribution
[ https://issues.apache.org/jira/browse/TUSCANY-2119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino reassigned TUSCANY-2119: --- Assignee: Jean-Sebastien Delfino Eclipse plugin jars missing from the distribution - Key: TUSCANY-2119 URL: https://issues.apache.org/jira/browse/TUSCANY-2119 Project: Tuscany Issue Type: Bug Components: Build System Affects Versions: Java-SCA-1.2 Reporter: Jean-Sebastien Delfino Assignee: Jean-Sebastien Delfino Fix For: Java-SCA-1.2 The JARs from tools/eclipse/plugins are missing from the distribution. -- 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] Commented: (TUSCANY-2119) Eclipse plugin jars missing from the distribution
[ https://issues.apache.org/jira/browse/TUSCANY-2119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12581857#action_12581857 ] Jean-Sebastien Delfino commented on TUSCANY-2119: - In SVN revisions r640755 (trunk) and r640756 (1.2 branch) the plugin build has been fixed to produce a correct updatesite referencing the Tuscany bin and src distros. To use it, try the following: - unzip apache-tuscany-sca-updatesite.zip in the directory containing the Tuscany bin and source distros - update your Eclipse from the update site - the Eclipse update manager will then install the Tuscany SCA tool feature as well as the Tuscany bin and source distros - a Tuscany Library buildpath library entry will be created in your IDE, pointing to the Tuscany JARs and the corresponding source attachment - create a project, add the Tuscany library to its buildpath, .composite, click Run As / Tuscany to run it. Eclipse plugin jars missing from the distribution - Key: TUSCANY-2119 URL: https://issues.apache.org/jira/browse/TUSCANY-2119 Project: Tuscany Issue Type: Bug Components: Build System Affects Versions: Java-SCA-1.2 Reporter: Jean-Sebastien Delfino Assignee: Jean-Sebastien Delfino Fix For: Java-SCA-1.2 The JARs from tools/eclipse/plugins are missing from the distribution. -- 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] Commented: (TUSCANY-2120) Admin start button only works if the target node is on localhost
[ https://issues.apache.org/jira/browse/TUSCANY-2120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12582018#action_12582018 ] Jean-Sebastien Delfino commented on TUSCANY-2120: - There's one more small fix required to get this fixed, to allow the node to specify the port number of where to reach the admin service that will start/stop it. Admin start button only works if the target node is on localhost Key: TUSCANY-2120 URL: https://issues.apache.org/jira/browse/TUSCANY-2120 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-1.2 Reporter: Jean-Sebastien Delfino Assignee: Jean-Sebastien Delfino Fix For: Java-SCA-1.2 The Start button in the admin app only works if the node is configured to run on localhost, it should send the start request to the specified host (from the node URI) instead. -- 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] Created: (TUSCANY-2136) Incorrect proxy injected for unwired SCA reference
Incorrect proxy injected for unwired SCA reference
---
Key: TUSCANY-2136
URL: https://issues.apache.org/jira/browse/TUSCANY-2136
Project: Tuscany
Issue Type: Bug
Components: Java SCA Core Runtime
Affects Versions: Java-SCA-1.2
Reporter: Jean-Sebastien Delfino
Fix For: Java-SCA-1.2
Discussed on tuscany-dev here: http://marc.info/?l=tuscany-devm=120615059020103
The latest code does not seem to handle the injection of unwired SCA
references correctly.
Here's how I set up my code:
class CustomerInfoServiceImpl {
@Reference(required = false)
public CustomerInfo customer;
...
}
In the .composite I don't wire the customer reference.
I still end up with a proxy injected into the customer field. I was
expecting the field to be null.
Calling a business method on that proxy throws an exception
Service not found for component AtomAggregator reference customer
(bindingURI=null operation=getCustomerInfo). Ensure that the composite
containing the service is loaded and started somewhere in the SCA domain
and that if running in a remote node that the interface of the target
service marked as @Remotable
and that message is pretty misleading too :)
Any idea of what's going wrong with injection?
--
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] Commented: (TUSCANY-2119) Eclipse plugin jars missing from the distribution
[ https://issues.apache.org/jira/browse/TUSCANY-2119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12582094#action_12582094 ] Jean-Sebastien Delfino commented on TUSCANY-2119: - Luciano, let me know if you need anything else for this, the only thing left that I can think of is to copy the updatesite Zip to the distribution/target directory when the distribution gets built, to have it besides the other zips. Eclipse plugin jars missing from the distribution - Key: TUSCANY-2119 URL: https://issues.apache.org/jira/browse/TUSCANY-2119 Project: Tuscany Issue Type: Bug Components: Build System Affects Versions: Java-SCA-1.2 Reporter: Jean-Sebastien Delfino Assignee: Jean-Sebastien Delfino Fix For: Java-SCA-1.2 The JARs from tools/eclipse/plugins are missing from the distribution. -- 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] Resolved: (TUSCANY-1840) Bootstrapping a subset of Tuscany runtime to support object modeling in tools
[ https://issues.apache.org/jira/browse/TUSCANY-1840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino resolved TUSCANY-1840. - Resolution: Cannot Reproduce There's now a lot of code (in particular in the workspace-admin module) showing that it's possible to bootstrap the subset of Tuscany required by the Tuscany assembly model, using the Tuscany SPIs, and without bootstrapping the whole runtime. There is not enough in this JIRA description to understand if there really is an issue. Could you please reopen this issue with a description of your specific requirements if they are not met by the current SPIs? Thanks. Bootstrapping a subset of Tuscany runtime to support object modeling in tools - Key: TUSCANY-1840 URL: https://issues.apache.org/jira/browse/TUSCANY-1840 Project: Tuscany Issue Type: New Feature Components: Java SCA Core Runtime Affects Versions: Java-SCA-1.0 Environment: Windows or Linux Reporter: Sean Zhou Fix For: Java-SCA-Next When adopting Tuscany object models in a tooling environment, a subset of Tuscany runtime requires bootstrap such as creating extension points and factories. Currently there are no standard API methods or classes for Tuscany bootstrapping for modeling. -- 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] Resolved: (TUSCANY-2120) Admin start button only works if the target node is on localhost
[ https://issues.apache.org/jira/browse/TUSCANY-2120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino resolved TUSCANY-2120. - Resolution: Fixed Fixed in trunk and the 1.2 branch. Admin start button only works if the target node is on localhost Key: TUSCANY-2120 URL: https://issues.apache.org/jira/browse/TUSCANY-2120 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-1.2 Reporter: Jean-Sebastien Delfino Assignee: Jean-Sebastien Delfino Fix For: Java-SCA-1.2 The Start button in the admin app only works if the node is configured to run on localhost, it should send the start request to the specified host (from the node URI) instead. -- 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] Created: (TUSCANY-2137) Incorrect names for notification sample jars
Incorrect names for notification sample jars Key: TUSCANY-2137 URL: https://issues.apache.org/jira/browse/TUSCANY-2137 Project: Tuscany Issue Type: Bug Components: Build System Affects Versions: Java-SCA-1.2 Reporter: Jean-Sebastien Delfino Fix For: Java-SCA-1.2 The notification sample JARs are not named like the other sample JARs, they still carry the release version number. Their poms is probably missing a finalName element. -- 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] Commented: (TUSCANY-2117) SCA Distributions missing tutorial projects
[ https://issues.apache.org/jira/browse/TUSCANY-2117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12581487#action_12581487 ] Jean-Sebastien Delfino commented on TUSCANY-2117: - I've cleaned up the tutorial modules in SVN revisions r640322 (trunk) and r640325 (1.2 branch), so they should be OK to include in the distro now. Modules tutorial/jee-services (formerly nodes-jee) and tutorial/www-services should be excluded as they don't work yet. SCA Distributions missing tutorial projects --- Key: TUSCANY-2117 URL: https://issues.apache.org/jira/browse/TUSCANY-2117 Project: Tuscany Issue Type: Bug Components: Java SCA Samples Affects Versions: Java-SCA-1.2 Reporter: Luciano Resende Assignee: Luciano Resende Fix For: Java-SCA-1.2 -- 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] Commented: (TUSCANY-2115) Clean-up 1.2 branch from obsolete and/or contrib modules
[ https://issues.apache.org/jira/browse/TUSCANY-2115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12581488#action_12581488 ] Jean-Sebastien Delfino commented on TUSCANY-2115: - I've cleaned up the tutorial modules in SVN revisions r640322 (trunk) and r640325 (1.2 branch), so they should be OK to include in the distro now. Modules tutorial/jee-services (formerly nodes-jee) and tutorial/www-services should be excluded as they don't work yet. Clean-up 1.2 branch from obsolete and/or contrib modules Key: TUSCANY-2115 URL: https://issues.apache.org/jira/browse/TUSCANY-2115 Project: Tuscany Issue Type: Bug Affects Versions: Java-SCA-1.2 Reporter: Luciano Resende Assignee: Luciano Resende Fix For: Java-SCA-1.2 Possible modules to clean : - itest/interop-soap-client - itest/interop-soap-round2-client - itest/interop-soap-service - modules/implementation-openjpa - tools/maven-definitions - tools/maven-dependency-lister Possible others - modules/implementation-das - modules/implementation-data-xml - modules/node ? - modules/node-api ? - modules/node-impl ? Please add comments with modules you want to add or remove to the list -- 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] Created: (TUSCANY-2128) Store sample should include fixes and improvements from the store tutorial
Store sample should include fixes and improvements from the store tutorial -- Key: TUSCANY-2128 URL: https://issues.apache.org/jira/browse/TUSCANY-2128 Project: Tuscany Issue Type: Bug Components: Java SCA Samples Affects Versions: Java-SCA-1.2 Reporter: Jean-Sebastien Delfino Assignee: Jean-Sebastien Delfino Fix For: Java-SCA-1.2 The store sample should be brought in line with the bigger store from the tutorial, as a number of improvements have gone into the tutorial version of the store, including: - client HTML + javascript fixes - using the simpler data collection interface instead of an Abdera feed - using beans instead of strings to represent items in the store -- 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] Resolved: (TUSCANY-2128) Store sample should include fixes and improvements from the store tutorial
[ https://issues.apache.org/jira/browse/TUSCANY-2128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino resolved TUSCANY-2128. - Resolution: Fixed Fixed in trunk in SVN r640331 and the 1.2 branch in SVN r640337. Store sample should include fixes and improvements from the store tutorial -- Key: TUSCANY-2128 URL: https://issues.apache.org/jira/browse/TUSCANY-2128 Project: Tuscany Issue Type: Bug Components: Java SCA Samples Affects Versions: Java-SCA-1.2 Reporter: Jean-Sebastien Delfino Assignee: Jean-Sebastien Delfino Fix For: Java-SCA-1.2 The store sample should be brought in line with the bigger store from the tutorial, as a number of improvements have gone into the tutorial version of the store, including: - client HTML + javascript fixes - using the simpler data collection interface instead of an Abdera feed - using beans instead of strings to represent items in the store -- 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] Resolved: (TUSCANY-2024) Missing maven-incremental-build source files in release source distro
[ https://issues.apache.org/jira/browse/TUSCANY-2024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino resolved TUSCANY-2024. - Resolution: Fixed This is now resolved in 1.2. Missing maven-incremental-build source files in release source distro - Key: TUSCANY-2024 URL: https://issues.apache.org/jira/browse/TUSCANY-2024 Project: Tuscany Issue Type: Bug Components: Build System Affects Versions: Java-SCA-1.1 Reporter: Jean-Sebastien Delfino Priority: Minor Fix For: Java-SCA-1.2 Reported on tuscany-dev in http://marc.info/?l=tuscany-devm=120170144819429 The maven-incremental-build source files are missing from the source distro. This does not break the build and is a minor issue as that maven-incremental-build plugin is only used by some of us to run incremental builds of the Tuscany tree at development time. -- 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] Commented: (TUSCANY-2119) Eclipse plugin jars missing from the distribution
[ https://issues.apache.org/jira/browse/TUSCANY-2119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12581614#action_12581614 ] Jean-Sebastien Delfino commented on TUSCANY-2119: - Actually we only need the updatesite zip (assembled by the updatesite module under tools). I noticed that the updateside still references 1.0.0, I'll try to fix it later today. Eclipse plugin jars missing from the distribution - Key: TUSCANY-2119 URL: https://issues.apache.org/jira/browse/TUSCANY-2119 Project: Tuscany Issue Type: Bug Components: Build System Affects Versions: Java-SCA-1.2 Reporter: Jean-Sebastien Delfino Fix For: Java-SCA-1.2 The JARs from tools/eclipse/plugins are missing from the distribution. -- 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] Created: (TUSCANY-2131) Javascript-based UI does not work on IE
Javascript-based UI does not work on IE --- Key: TUSCANY-2131 URL: https://issues.apache.org/jira/browse/TUSCANY-2131 Project: Tuscany Issue Type: Bug Components: Java SCA Samples Affects Versions: Java-SCA-1.2 Reporter: Jean-Sebastien Delfino Assignee: Jean-Sebastien Delfino Fix For: Java-SCA-1.2 The various Javascript-based UI in samples and the workspace admin do not work on IE. That's because they try to init the HTML DOM to early before it's created by IE. A simple fix is to execute that init code in the from the body.onload event. I'll try to commit fixes for that issue later today. -- 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] Commented: (TUSCANY-2117) SCA Distributions missing tutorial projects
[ https://issues.apache.org/jira/browse/TUSCANY-2117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12581618#action_12581618 ] Jean-Sebastien Delfino commented on TUSCANY-2117: - However www-services will still need to be excluded. SCA Distributions missing tutorial projects --- Key: TUSCANY-2117 URL: https://issues.apache.org/jira/browse/TUSCANY-2117 Project: Tuscany Issue Type: Bug Components: Java SCA Samples Affects Versions: Java-SCA-1.2 Reporter: Luciano Resende Assignee: Luciano Resende Fix For: Java-SCA-1.2 -- 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] Commented: (TUSCANY-2117) SCA Distributions missing tutorial projects
[ https://issues.apache.org/jira/browse/TUSCANY-2117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12581617#action_12581617 ] Jean-Sebastien Delfino commented on TUSCANY-2117: - I'm looking into getting the jee-services module working too (on Geronimo). So if it works we won't have to exclude it :) I'll report on my progress in this JIRA later today. SCA Distributions missing tutorial projects --- Key: TUSCANY-2117 URL: https://issues.apache.org/jira/browse/TUSCANY-2117 Project: Tuscany Issue Type: Bug Components: Java SCA Samples Affects Versions: Java-SCA-1.2 Reporter: Luciano Resende Assignee: Luciano Resende Fix For: Java-SCA-1.2 -- 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] Resolved: (TUSCANY-2131) Javascript-based UI does not work on IE
[ https://issues.apache.org/jira/browse/TUSCANY-2131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino resolved TUSCANY-2131. - Resolution: Fixed Fixed in trunk and the 1.2 branch. Javascript-based UI does not work on IE --- Key: TUSCANY-2131 URL: https://issues.apache.org/jira/browse/TUSCANY-2131 Project: Tuscany Issue Type: Bug Components: Java SCA Samples Affects Versions: Java-SCA-1.2 Reporter: Jean-Sebastien Delfino Assignee: Jean-Sebastien Delfino Fix For: Java-SCA-1.2 The various Javascript-based UI in samples and the workspace admin do not work on IE. That's because they try to init the HTML DOM to early before it's created by IE. A simple fix is to execute that init code in the from the body.onload event. I'll try to commit fixes for that issue later today. -- 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] Commented: (TUSCANY-2132) Building Apache Tuscany SCA Contribution Model Implementation fails while testing
[ https://issues.apache.org/jira/browse/TUSCANY-2132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12581765#action_12581765 ] Jean-Sebastien Delfino commented on TUSCANY-2132: - Hi Mario, It seems to be OK in the continuum daily build. Could you please try to do mvn clean install on the dependencies (like contribution)? I'm thinking that you may have old versions of these dependencies, out of sync with contribution-impl. Hope this helps. Building Apache Tuscany SCA Contribution Model Implementation fails while testing - Key: TUSCANY-2132 URL: https://issues.apache.org/jira/browse/TUSCANY-2132 Project: Tuscany Issue Type: Bug Reporter: Mario Antollini Priority: Minor The module contribution-impl does not build correctly since there are 4 errors while testing... Running org.apache.tuscany.sca.contribution.impl.ContributionClassLoaderTestCase Tests run: 4, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 0.093 sec FAILURE! testResourceLoadingFromImportedContribution(org.apache.tuscany.sca.contribution.impl.ContributionClassLoaderTestCase) Time elapsed: 0.031 sec ERROR! java.lang.NoSuchMethodError: setExportContributions at org.apache.tuscany.sca.contribution.impl.ContributionClassLoaderTestCase.testResourceLoadingFromImportedContribution(ContributionClass LoaderTestCase.java:224) at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source) at java.lang.reflect.Method.invoke(Ljava.lang.Object;[Ljava.lang.Object;I)Ljava.lang.Object;(Unknown Source) at org.junit.internal.runners.TestMethodRunner.executeMethodBody(TestMethodRunner.java:99) at org.junit.internal.runners.TestMethodRunner.runUnprotected(TestMethodRunner.java:81) at org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34) at org.junit.internal.runners.TestMethodRunner.runMethod(TestMethodRunner.java:75) at org.junit.internal.runners.TestMethodRunner.run(TestMethodRunner.java:45) at org.junit.internal.runners.TestClassMethodsRunner.invokeTestMethod(TestClassMethodsRunner.java:75) at org.junit.internal.runners.TestClassMethodsRunner.run(TestClassMethodsRunner.java:36) at org.junit.internal.runners.TestClassRunner$1.runUnprotected(TestClassRunner.java:42) at org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34) at org.junit.internal.runners.TestClassRunner.run(TestClassRunner.java:52) at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:125) at org.apache.maven.surefire.Surefire.run(Surefire.java:132) at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source) at java.lang.reflect.Method.invoke(Ljava.lang.Object;[Ljava.lang.Object;I)Ljava.lang.Object;(Unknown Source) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:308) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:879) testClassLoadingFromImportedContribution(org.apache.tuscany.sca.contribution.impl.ContributionClassLoaderTestCase) Time elapsed: 0.016 sec ERROR! java.lang.NoSuchMethodError: setExportContributions at org.apache.tuscany.sca.contribution.impl.ContributionClassLoaderTestCase.testClassLoadingFromImportedContribution(ContributionClassLoa derTestCase.java:152) at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source) at java.lang.reflect.Method.invoke(Ljava.lang.Object;[Ljava.lang.Object;I)Ljava.lang.Object;(Unknown Source) at org.junit.internal.runners.TestMethodRunner.executeMethodBody(TestMethodRunner.java:99) at org.junit.internal.runners.TestMethodRunner.runUnprotected(TestMethodRunner.java:81) at org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34) at org.junit.internal.runners.TestMethodRunner.runMethod(TestMethodRunner.java:75) at org.junit.internal.runners.TestMethodRunner.run(TestMethodRunner.java:45) at org.junit.internal.runners.TestClassMethodsRunner.invokeTestMethod(TestClassMethodsRunner.java:75) at
[jira] Created: (TUSCANY-2133) All composites should be deployable if there's no sca-contribution.xml
All composites should be deployable if there's no sca-contribution.xml -- Key: TUSCANY-2133 URL: https://issues.apache.org/jira/browse/TUSCANY-2133 Project: Tuscany Issue Type: Bug Components: Java SCA Assembly Model Affects Versions: Java-SCA-1.2 Reporter: Jean-Sebastien Delfino Assignee: Jean-Sebastien Delfino Fix For: Java-SCA-1.2 The domain admin should mark all composites as deployables in contributions that do not contain an sca-contribution.xml file. Currently the app developer is forced to write an sca-contribution.xml file to mark his composites deployables. That file is actually optional so that's a serious limitation. -- 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] Resolved: (TUSCANY-2133) All composites should be deployable if there's no sca-contribution.xml
[ https://issues.apache.org/jira/browse/TUSCANY-2133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino resolved TUSCANY-2133. - Resolution: Fixed Fixed in trunk SVN r640692 and r640693 and 1.2 branch SVN r640694. All composites should be deployable if there's no sca-contribution.xml -- Key: TUSCANY-2133 URL: https://issues.apache.org/jira/browse/TUSCANY-2133 Project: Tuscany Issue Type: Bug Components: Java SCA Assembly Model Affects Versions: Java-SCA-1.2 Reporter: Jean-Sebastien Delfino Assignee: Jean-Sebastien Delfino Fix For: Java-SCA-1.2 The domain admin should mark all composites as deployables in contributions that do not contain an sca-contribution.xml file. Currently the app developer is forced to write an sca-contribution.xml file to mark his composites deployables. That file is actually optional so that's a serious limitation. -- 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] Created: (TUSCANY-2118) AtomBindingInvoker handling out of sync with Collection interface
AtomBindingInvoker handling out of sync with Collection interface - Key: TUSCANY-2118 URL: https://issues.apache.org/jira/browse/TUSCANY-2118 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-1.2 Reporter: Jean-Sebastien Delfino Assignee: Jean-Sebastien Delfino Fix For: Java-SCA-1.2 The AtomBindingInvoker does not correctly implement all the methods on the binding Collection interface, and is also missing the implementation of the methods on the data Collection interface, making it not really usable. I'm working on a fix for that issue. -- 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] Created: (TUSCANY-2119) Eclipse plugin jars missing from the distribution
Eclipse plugin jars missing from the distribution - Key: TUSCANY-2119 URL: https://issues.apache.org/jira/browse/TUSCANY-2119 Project: Tuscany Issue Type: Bug Components: Build System Affects Versions: Java-SCA-1.2 Reporter: Jean-Sebastien Delfino Fix For: Java-SCA-1.2 The JARs from tools/eclipse/plugins are missing from the distribution. -- 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] Created: (TUSCANY-2120) Admin start button only works if the target node is on localhost
Admin start button only works if the target node is on localhost Key: TUSCANY-2120 URL: https://issues.apache.org/jira/browse/TUSCANY-2120 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-1.2 Reporter: Jean-Sebastien Delfino Assignee: Jean-Sebastien Delfino Fix For: Java-SCA-1.2 The Start button in the admin app only works if the node is configured to run on localhost, it should send the start request to the specified host (from the node URI) instead. -- 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] Commented: (TUSCANY-2118) AtomBindingInvoker handling out of sync with Collection interface
[ https://issues.apache.org/jira/browse/TUSCANY-2118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12581410#action_12581410 ] Jean-Sebastien Delfino commented on TUSCANY-2118: - I committed the fix to trunk only for now, in SVN revision 640230. AtomBindingInvoker handling out of sync with Collection interface - Key: TUSCANY-2118 URL: https://issues.apache.org/jira/browse/TUSCANY-2118 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-1.2 Reporter: Jean-Sebastien Delfino Assignee: Jean-Sebastien Delfino Fix For: Java-SCA-1.2 The AtomBindingInvoker does not correctly implement all the methods on the binding Collection interface, and is also missing the implementation of the methods on the data Collection interface, making it not really usable. I'm working on a fix for that issue. -- 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] Commented: (TUSCANY-2120) Admin start button only works if the target node is on localhost
[ https://issues.apache.org/jira/browse/TUSCANY-2120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12581411#action_12581411 ] Jean-Sebastien Delfino commented on TUSCANY-2120: - I committed a fix to trunk for now in SVN revision r640235. Admin start button only works if the target node is on localhost Key: TUSCANY-2120 URL: https://issues.apache.org/jira/browse/TUSCANY-2120 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-1.2 Reporter: Jean-Sebastien Delfino Assignee: Jean-Sebastien Delfino Fix For: Java-SCA-1.2 The Start button in the admin app only works if the node is configured to run on localhost, it should send the start request to the specified host (from the node URI) instead. -- 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] Created: (TUSCANY-2121) JAXB serialization of data Collection.Entry objects does not work
JAXB serialization of data Collection.Entry objects does not work - Key: TUSCANY-2121 URL: https://issues.apache.org/jira/browse/TUSCANY-2121 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-1.2 Reporter: Jean-Sebastien Delfino Fix For: Java-SCA-1.2 Data Collection.Entry objects used by the Atom and RSS cannot be serialized using JAXB, as JAXB does not handle generics and fails to register the Item class in its context. -- 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] Commented: (TUSCANY-2117) SCA Distributions missing tutorial projects
[ https://issues.apache.org/jira/browse/TUSCANY-2117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12581413#action_12581413 ] Jean-Sebastien Delfino commented on TUSCANY-2117: - I can help with this one if you want. If you do it, the nodes-jee and www-services modules should probably be excluded as they're not ready to work. SCA Distributions missing tutorial projects --- Key: TUSCANY-2117 URL: https://issues.apache.org/jira/browse/TUSCANY-2117 Project: Tuscany Issue Type: Bug Components: Java SCA Samples Affects Versions: Java-SCA-1.2 Reporter: Luciano Resende Assignee: Luciano Resende Fix For: Java-SCA-1.2 -- 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] Resolved: (TUSCANY-2118) AtomBindingInvoker handling out of sync with Collection interface
[ https://issues.apache.org/jira/browse/TUSCANY-2118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino resolved TUSCANY-2118. - Resolution: Fixed Fixed in 1.2 branch as well. AtomBindingInvoker handling out of sync with Collection interface - Key: TUSCANY-2118 URL: https://issues.apache.org/jira/browse/TUSCANY-2118 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-1.2 Reporter: Jean-Sebastien Delfino Assignee: Jean-Sebastien Delfino Fix For: Java-SCA-1.2 The AtomBindingInvoker does not correctly implement all the methods on the binding Collection interface, and is also missing the implementation of the methods on the data Collection interface, making it not really usable. I'm working on a fix for that issue. -- 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] Commented: (TUSCANY-2120) Admin start button only works if the target node is on localhost
[ https://issues.apache.org/jira/browse/TUSCANY-2120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12581471#action_12581471 ] Jean-Sebastien Delfino commented on TUSCANY-2120: - Merged the fix in the 1.2 branch. Admin start button only works if the target node is on localhost Key: TUSCANY-2120 URL: https://issues.apache.org/jira/browse/TUSCANY-2120 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-1.2 Reporter: Jean-Sebastien Delfino Assignee: Jean-Sebastien Delfino Fix For: Java-SCA-1.2 The Start button in the admin app only works if the node is configured to run on localhost, it should send the start request to the specified host (from the node URI) instead. -- 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] Resolved: (TUSCANY-2121) JAXB serialization of data Collection.Entry objects does not work
[ https://issues.apache.org/jira/browse/TUSCANY-2121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino resolved TUSCANY-2121. - Resolution: Fixed Fixed in 1.2 branch as well. JAXB serialization of data Collection.Entry objects does not work - Key: TUSCANY-2121 URL: https://issues.apache.org/jira/browse/TUSCANY-2121 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-1.2 Reporter: Jean-Sebastien Delfino Assignee: Jean-Sebastien Delfino Fix For: Java-SCA-1.2 Data Collection.Entry objects used by the Atom and RSS cannot be serialized using JAXB, as JAXB does not handle generics and fails to register the Item class in its context. -- 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] Resolved: (TUSCANY-1953) Feed-aggregator sample does not stop properly
[ https://issues.apache.org/jira/browse/TUSCANY-1953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino resolved TUSCANY-1953. - Resolution: Fixed This issue has been resolved. Feed-aggregator sample does not stop properly - Key: TUSCANY-1953 URL: https://issues.apache.org/jira/browse/TUSCANY-1953 Project: Tuscany Issue Type: Bug Components: Java SCA Tomcat Integration Affects Versions: Java-SCA-1.1 Reporter: Jean-Sebastien Delfino Assignee: Jean-Sebastien Delfino Fix For: Java-SCA-1.2 To reproduce the problem, start the feed-aggregator sample using ant run, point your Web browser to http://localhost:8083/atomAggregator, then press enter in the window where you started ant run. The program should exit but doesn't. The problem is that ThreadPoolWorkManager used by the TomcatServer to handle incoming HTTP requests and read from the input TCP/IP socket does not create Daemon threads. Tomcat leaves a thread alive blocked on the input socket and that live thread prevents the JVM to exit. This problem is not specific to the feed-aggregator sample, it happens with any Tuscany application using our embedded TomcatServer. The problem does not occur with Jetty. I am fixing it by marking the threads as Daemon threads in ThreadWorkPoolManager. -- 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]
