[jira] Commented: (TUSCANY-715) Update tools module to use latest XmlSchema version
[ http://issues.apache.org/jira/browse/TUSCANY-715?page=comments#action_12434221 ] Jeremy Boynes commented on TUSCANY-715: --- Patch applied - thanks > Update tools module to use latest XmlSchema version > --- > > Key: TUSCANY-715 > URL: http://issues.apache.org/jira/browse/TUSCANY-715 > Project: Tuscany > Issue Type: Bug > Components: Java SCA Tools >Reporter: Jeremy Boynes >Priority: Critical > Attachments: Tuscany-SCA-Tools-Patch-Sept-12.diff > > > The API for XmlSchema has changed since the 1.0.2 version. We are using a > newer version due to updates in Axis2 and the tools need to be modified to > use its new API. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-642) Composite references and services - model and runtime representations
[ http://issues.apache.org/jira/browse/TUSCANY-642?page=comments#action_12434472 ] Jeremy Boynes commented on TUSCANY-642: --- CommentsOut patch applied - thanks > Composite references and services - model and runtime representations > - > > Key: TUSCANY-642 > URL: http://issues.apache.org/jira/browse/TUSCANY-642 > Project: Tuscany > Issue Type: New Feature > Components: Java SCA Core >Affects Versions: Java-Mx >Reporter: Ignacio Silva-Lepe > Assigned To: Jim Marino > Fix For: Java-Mx > > Attachments: CommentsOut.patch, CompositeRefsAndSvcs.txt, > CompositeRefsAndSvcs2.txt, InnerComposite.patch, > InnerCompositeCallback.patch, InnerCompositeCallback2.patch, > RevisedInnerCompositeCallback.patch > > > Support is added to represent composite references and services (those in a > composite and without a binding) in the model and runtime. The > CompositeBuilder is updated to build a composite component that includes > composite references and services without bindings. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-723) Repository entry missing in SCA tools
[ http://issues.apache.org/jira/browse/TUSCANY-723?page=all ] Jeremy Boynes closed TUSCANY-723. - Resolution: Fixed Patch applied - thanks > Repository entry missing in SCA tools > - > > Key: TUSCANY-723 > URL: http://issues.apache.org/jira/browse/TUSCANY-723 > Project: Tuscany > Issue Type: Bug > Components: Java SCA Tools >Affects Versions: Java-M2 > Environment: WinXP >Reporter: Lee Surprenant >Priority: Blocker > Attachments: SCAToolsPomUpdate.patch > > > SCA tools build fails due to missing repository for org.eclipse.emf > Missing: > -- > 1) org.eclipse.emf:codegen-ecore:jar:2.2.0 > Try downloading the file manually from the project website. > Then, install it using the command: >mvn install:install-file -DgroupId=org.eclipse.emf > -DartifactId=codegen-e > ore \ >-Dversion=2.2.0 -Dpackaging=jar -Dfile=/path/to/file > >Path to dependency: > 1) org.apache.tuscany:sca-tools:jar:1.0-incubator-M2-SNAPSHOT > 2) org.eclipse.emf:codegen-ecore:jar:2.2.0 > > 2) org.eclipse.emf:codegen:jar:2.2.0 > > Try downloading the file manually from the project website. > > Then, install it using the command: > mvn install:install-file -DgroupId=org.eclipse.emf -DartifactId=codegen > \ >-Dversion=2.2.0 -Dpackaging=jar -Dfile=/path/to/file > > Path to dependency: > 1) org.apache.tuscany:sca-tools:jar:1.0-incubator-M2-SNAPSHOT > 2) org.eclipse.emf:codegen:jar:2.2.0 > > -- -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-728) Upgrade to AXIOM 1.1
Upgrade to AXIOM 1.1 Key: TUSCANY-728 URL: http://issues.apache.org/jira/browse/TUSCANY-728 Project: Tuscany Issue Type: Improvement Affects Versions: Java-M2 Reporter: Jeremy Boynes Fix For: Java-M2 AXIOM have now released 1.1 so we should migrate off SNAPSHOTs -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-731) Update jsonRPC pom files to fix compilation errors
[ http://issues.apache.org/jira/browse/TUSCANY-731?page=all ] Jeremy Boynes closed TUSCANY-731. - Resolution: Cannot Reproduce Looks like this has already been fixed > Update jsonRPC pom files to fix compilation errors > -- > > Key: TUSCANY-731 > URL: http://issues.apache.org/jira/browse/TUSCANY-731 > Project: Tuscany > Issue Type: Bug > Components: Java SCA Samples >Affects Versions: Java-M2 >Reporter: Luciano Resende > Fix For: Java-M2 > > Attachments: tuscany731.lresende.20060918.txt > > > jsonRPC not building due to wrong references in pom.xml -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-733) Version information should not be in war plugin source code
Version information should not be in war plugin source code --- Key: TUSCANY-733 URL: http://issues.apache.org/jira/browse/TUSCANY-733 Project: Tuscany Issue Type: Bug Components: Maven Plugins Affects Versions: Java-M2 Reporter: Jeremy Boynes The version of the runtime to use should be a configuration property of the war plugin and not hard coded in Dependency. Ideally, the default value for runtime version should come from a POM property, perhaps the version of the POM plugin itself. A user of the plugin should be able to override this in their own project with a configuration property -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (TUSCANY-648) Launcher only runs from jars on the file system
[ http://issues.apache.org/jira/browse/TUSCANY-648?page=all ] Jeremy Boynes reassigned TUSCANY-648: - Assignee: Jeremy Boynes > Launcher only runs from jars on the file system > --- > > Key: TUSCANY-648 > URL: http://issues.apache.org/jira/browse/TUSCANY-648 > Project: Tuscany > Issue Type: Bug > Components: Java SCA Core >Affects Versions: Java-M2 >Reporter: ant elder > Assigned To: Jeremy Boynes >Priority: Minor > Fix For: Java-M2 > > > The o.a.t.core.launcher.LauncherImpl method getInstallDirectory throws an > exception if the LauncherImpl class is not loaded from a jar on the file > system. This isn't the case when running in a webapp using the new > TuscanyContextListener. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-728) Upgrade to AXIOM 1.1
[ http://issues.apache.org/jira/browse/TUSCANY-728?page=comments#action_12436235 ] Jeremy Boynes commented on TUSCANY-728: --- AXIOM 1.1.1 has also been released > Upgrade to AXIOM 1.1 > > > Key: TUSCANY-728 > URL: http://issues.apache.org/jira/browse/TUSCANY-728 > Project: Tuscany > Issue Type: Improvement >Affects Versions: Java-M2 >Reporter: Jeremy Boynes > Fix For: Java-M2 > > > AXIOM have now released 1.1 so we should migrate off SNAPSHOTs -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-736) Upgrade to XmlSchema 1.1
Upgrade to XmlSchema 1.1 Key: TUSCANY-736 URL: http://issues.apache.org/jira/browse/TUSCANY-736 Project: Tuscany Issue Type: Bug Reporter: Jeremy Boynes XmlSchema 1.1 has been released so we should migrate off SNAPSHOTs -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (TUSCANY-738) tuscany war plugin and default runtime location of extensions seem to be out of sync
[ http://issues.apache.org/jira/browse/TUSCANY-738?page=all ] Jeremy Boynes reassigned TUSCANY-738: - Assignee: Jeremy Boynes > tuscany war plugin and default runtime location of extensions seem to be out > of sync > > > Key: TUSCANY-738 > URL: http://issues.apache.org/jira/browse/TUSCANY-738 > Project: Tuscany > Issue Type: Bug > Components: Java SCA Tomcat Integration, Maven Plugins >Affects Versions: Java-M2 >Reporter: Rick Rineholt > Assigned To: Jeremy Boynes >Priority: Critical > Fix For: Java-M2 > > > By default the tuscany war plugin is put extensions in > WEB-INF/tuscany/extensions while by default the runtime is searching for it > here: -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-738) tuscany war plugin and default runtime location of extensions seem to be out of sync
[ http://issues.apache.org/jira/browse/TUSCANY-738?page=comments#action_12436290 ] Jeremy Boynes commented on TUSCANY-738: --- The plugin is right - I'm working on cleaning up the launch code and will include this in that. > tuscany war plugin and default runtime location of extensions seem to be out > of sync > > > Key: TUSCANY-738 > URL: http://issues.apache.org/jira/browse/TUSCANY-738 > Project: Tuscany > Issue Type: Bug > Components: Java SCA Tomcat Integration, Maven Plugins >Affects Versions: Java-M2 >Reporter: Rick Rineholt > Assigned To: Jeremy Boynes >Priority: Critical > Fix For: Java-M2 > > > By default the tuscany war plugin is put extensions in > WEB-INF/tuscany/extensions while by default the runtime is searching for it > here: -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-762) Shutdown hang
Shutdown hang - Key: TUSCANY-762 URL: http://issues.apache.org/jira/browse/TUSCANY-762 Project: Tuscany Issue Type: Bug Components: Java SCA Core Affects Versions: Java-M2 Reporter: Jeremy Boynes Assigned To: Jim Marino Priority: Critical When shutting down the runtime, stopping parent components can hang if the child has already been stopped because checkInit waits for the child to be started. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-797) standalone-1.0-incubator-M2-SNAPSHOT-bin.zip is missing 2 jar files
[ http://issues.apache.org/jira/browse/TUSCANY-797?page=all ]
Jeremy Boynes resolved TUSCANY-797.
---
Fix Version/s: Java-M2
Resolution: Fixed
Assignee: Jeremy Boynes
I added a lib directory for jars that get pulled in on the manifest classpath
for the command (using ../lib/${dep} ) and updated the standalone assembly so
that all of them get added to the zip/tgz archive
They are not needed in the boot directory as the classloader used for those
jars is a child of the system classloader containing the ones from lib (via
manifest Class-Path inclusion in the command jar).
Hopefully this resolves this issue - I tested running the calculator sample
from the command line and it worked for me
> standalone-1.0-incubator-M2-SNAPSHOT-bin.zip is missing 2 jar files
> ---
>
> Key: TUSCANY-797
> URL: http://issues.apache.org/jira/browse/TUSCANY-797
> Project: Tuscany
> Issue Type: Bug
> Components: Build System, Java SCA Core
>Affects Versions: Java-M2
> Environment: Windows XP SP2, Sun JDK 1.5.0_06-b5
>Reporter: Simon Nash
> Assigned To: Jeremy Boynes
> Fix For: Java-M2
>
>
> standalone-1.0-incubator-M2-SNAPSHOT-bin.zip is missing the following jar
> files from its bin directory:
>tuscany-host-api-1.0-incubator-M2-SNAPSHOT.jar
>tuscany-api-1.0-incubator-M2-SNAPSHOT.jar
> These jars are present in the bin directory of
> standalone-1.0-incubator-M2-SNAPSHOT-bin.tar.gz.
> Without these jars, attempting to run the calculator sample produces the error
> Exception in thread "main" java.lang.NoClassDefFoundError:
> org/apache/tuscany/host/RuntimeInfo
> With these jars, the calculator sample runs OK
> I checked the contents of standalone-1.0-incubator-M2-SNAPSHOT-bin.zip and
> standalone-1.0-incubator-M2-SNAPSHOT-bin.tar.gz for other differences and I
> found that the same 2 jars
>tuscany-host-api-1.0-incubator-M2-SNAPSHOT.jar
>tuscany-api-1.0-incubator-M2-SNAPSHOT.jar
> are present in the boot directory of
> standalone-1.0-incubator-M2-SNAPSHOT-bin.tar.gz but not in the boot directory
> of standalone-1.0-incubator-M2-SNAPSHOT-bin.zip.
> Having these jars missing from the boot directory does not impact successful
> execution of the calculator sample.
> It appears that the following actions are needed:
> 1. Add these 2 jars to the bin directory of
> standalone-1.0-incubator-M2-SNAPSHOT-bin.zip
> 2. Determine whether or not these jars are also needed in the boot
> directory. If so, add them to the boot directory of
> standalone-1.0-incubator-M2-SNAPSHOT-bin.zip. If not, remove them from the
> boot directory of standalone-1.0-incubator-M2-SNAPSHOT-bin.tar.gz.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-806) Licensing issues around DTDs used by checkstyle
Licensing issues around DTDs used by checkstyle --- Key: TUSCANY-806 URL: http://issues.apache.org/jira/browse/TUSCANY-806 Project: Tuscany Issue Type: Bug Reporter: Jeremy Boynes Priority: Blocker The buildtools module contains two DTDs that are used by the checkstyle plugin. They have no license info in them just a reference to the online source at http://www.puppycrawl.com which appears to be (c) Oliver Burn All Rights Reserved As such we may not be able to redistribute them. We need to clarify any redistribution rights and include those in the NOTICE for that module or remove them from any distribution. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (TUSCANY-806) Licensing issues around DTDs used by checkstyle
[ http://issues.apache.org/jira/browse/TUSCANY-806?page=all ] Jeremy Boynes reassigned TUSCANY-806: - Assignee: Jim Marino Assigning to jmarino as the original contributor to the project. > Licensing issues around DTDs used by checkstyle > --- > > Key: TUSCANY-806 > URL: http://issues.apache.org/jira/browse/TUSCANY-806 > Project: Tuscany > Issue Type: Bug >Reporter: Jeremy Boynes > Assigned To: Jim Marino >Priority: Blocker > > The buildtools module contains two DTDs that are used by the checkstyle > plugin. They have no license info in them just a reference to the online > source at http://www.puppycrawl.com which appears to be (c) Oliver Burn All > Rights Reserved > As such we may not be able to redistribute them. We need to clarify any > redistribution rights and include those in the NOTICE for that module or > remove them from any distribution. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-797) standalone-1.0-incubator-M2-SNAPSHOT-bin.zip is missing 2 jar files
[ http://issues.apache.org/jira/browse/TUSCANY-797?page=all ] Jeremy Boynes closed TUSCANY-797. - Assignee: (was: Jeremy Boynes) Thanks Simon > standalone-1.0-incubator-M2-SNAPSHOT-bin.zip is missing 2 jar files > --- > > Key: TUSCANY-797 > URL: http://issues.apache.org/jira/browse/TUSCANY-797 > Project: Tuscany > Issue Type: Bug > Components: Build System, Java SCA Core >Affects Versions: Java-M2 > Environment: Windows XP SP2, Sun JDK 1.5.0_06-b5 >Reporter: Simon Nash > Fix For: Java-M2 > > > standalone-1.0-incubator-M2-SNAPSHOT-bin.zip is missing the following jar > files from its bin directory: >tuscany-host-api-1.0-incubator-M2-SNAPSHOT.jar >tuscany-api-1.0-incubator-M2-SNAPSHOT.jar > These jars are present in the bin directory of > standalone-1.0-incubator-M2-SNAPSHOT-bin.tar.gz. > Without these jars, attempting to run the calculator sample produces the error > Exception in thread "main" java.lang.NoClassDefFoundError: > org/apache/tuscany/host/RuntimeInfo > With these jars, the calculator sample runs OK > I checked the contents of standalone-1.0-incubator-M2-SNAPSHOT-bin.zip and > standalone-1.0-incubator-M2-SNAPSHOT-bin.tar.gz for other differences and I > found that the same 2 jars >tuscany-host-api-1.0-incubator-M2-SNAPSHOT.jar >tuscany-api-1.0-incubator-M2-SNAPSHOT.jar > are present in the boot directory of > standalone-1.0-incubator-M2-SNAPSHOT-bin.tar.gz but not in the boot directory > of standalone-1.0-incubator-M2-SNAPSHOT-bin.zip. > Having these jars missing from the boot directory does not impact successful > execution of the calculator sample. > It appears that the following actions are needed: > 1. Add these 2 jars to the bin directory of > standalone-1.0-incubator-M2-SNAPSHOT-bin.zip > 2. Determine whether or not these jars are also needed in the boot > directory. If so, add them to the boot directory of > standalone-1.0-incubator-M2-SNAPSHOT-bin.zip. If not, remove them from the > boot directory of standalone-1.0-incubator-M2-SNAPSHOT-bin.tar.gz. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-806) Licensing issues around DTDs used by checkstyle
[ http://issues.apache.org/jira/browse/TUSCANY-806?page=all ] Jeremy Boynes resolved TUSCANY-806. --- Resolution: Fixed I removed the DTD files from our distro and removed the inline DOCTYPE declarations from the XML files. The checkstyle plugin requires XML validation and so will now need to access to the internet to run. This means that you will need to be online to use the "sourcecheck" maven profile. If this is being run just before a commit that is not too stringent a requirement as you would need to be online to commit anyway; however, this effectively prohibits us from including style checks in the default build. > Licensing issues around DTDs used by checkstyle > --- > > Key: TUSCANY-806 > URL: http://issues.apache.org/jira/browse/TUSCANY-806 > Project: Tuscany > Issue Type: Bug >Reporter: Jeremy Boynes > Assigned To: Jim Marino >Priority: Blocker > > The buildtools module contains two DTDs that are used by the checkstyle > plugin. They have no license info in them just a reference to the online > source at http://www.puppycrawl.com which appears to be (c) Oliver Burn All > Rights Reserved > As such we may not be able to redistribute them. We need to clarify any > redistribution rights and include those in the NOTICE for that module or > remove them from any distribution. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-833) ComponentType sidefiles do not work for Pojo Implementation
[ http://issues.apache.org/jira/browse/TUSCANY-833?page=comments#action_12441857 ] Jeremy Boynes commented on TUSCANY-833: --- Jim's proposal to the mailing list sounds like a better long-term solution but I am concerned that doing it this close to the release of M2 will be destabilizing. Propogating the approach used by the script containers does not provide the full function that we need from sidefiles - for example, it does not support scope and lifecycle method configuration that is available via annotation. I think we should tackle this problem as follows: 1. Create the branch using the code as it is today and document that sidefiles are not supported for Java components. This is the status quo. 2. Fix this in head the "right way" (whatever that is), assess the impact of that patch and consider applying it to the M2 branch before release. 3. Create a patch for the M2 branch that provides sidefile support with minimal destablization (however that can be done). The patches from 2 and 3 provide concrete implementations that we can evaluate for incorporation into M2, balancing the benefit of fixing the bug vs. the potential destabilization. > ComponentType sidefiles do not work for Pojo Implementation > --- > > Key: TUSCANY-833 > URL: http://issues.apache.org/jira/browse/TUSCANY-833 > Project: Tuscany > Issue Type: Bug > Components: Java SCA POJO Container >Affects Versions: Java-M2 >Reporter: Venkatakrishnan > Assigned To: Jim Marino >Priority: Critical > > If you have a component type sidefile for a Pojo implementation we end up > with an exception. The reason for this is that the JavaComponentTypeLoader > passes the PojoComponenType.class to the loader registry to be returned as a > result. However what gets created is an instance of the base ComponentType > and then there is an attempt to narrrow this to a PojoComponentType which > results in an exception. > A quick alternative in the interest of M2 fast approaching would be to take > the approach that the containers have to get over this problem which is for > the containers to get the base ComponentType and copy it over to the special > ones. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-838) Standalone launcher fails with NPE for ALL samples
[ http://issues.apache.org/jira/browse/TUSCANY-838?page=comments#action_12442028 ] Jeremy Boynes commented on TUSCANY-838: --- It works if you don't put in "--classpath" so that's a doc bug: $ java -jar bin/launcher.jar ~/.m2/repository/org/apache/tuscany/samples/sca/sample-calculator/1.0-incubator-M2-SNAPSHOT/sample-calculator-1.0-incubator-M2-SNAPSHOT.jar 3 + 2=5.0 3 - 2=1.0 3 * 2=6.0 3 / 2=1.5 We still need to handle the problem better and output a message rather than a stacktrace. > Standalone launcher fails with NPE for ALL samples > -- > > Key: TUSCANY-838 > URL: http://issues.apache.org/jira/browse/TUSCANY-838 > Project: Tuscany > Issue Type: Bug > Components: Java SCA Core >Affects Versions: Java-M2 >Reporter: ant elder > Assigned To: ant elder >Priority: Blocker > Fix For: Java-M2 > > > Trying to use the standalone launcher and it fails with NPE for ALL our > samples > C:\SCA\Standalone>java -jar bin\launcher.jar --classpath > ..\SVN\TRUNK\samples\sca\calculator\target\sample-calculator-1.0-incubator-M2-SNAPSHOT.jar > Exception in thread "main" java.lang.NullPointerException > at > org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistryImpl.java:102) > at > org.apache.tuscany.core.implementation.composite.CompositeComponentTypeLoader.loadFromSidefile(CompositeComponentTypeLoader.java:65) > at > org.apache.tuscany.core.implementation.composite.CompositeComponentTypeLoader.load(CompositeComponentTypeLoader.java:57) > at > org.apache.tuscany.core.implementation.composite.CompositeComponentTypeLoader.load(CompositeComponentTypeLoader.java:39) > at > org.apache.tuscany.core.loader.LoaderRegistryImpl.loadComponentType(LoaderRegistryImpl.java:159) > at > org.apache.tuscany.core.deployer.DeployerImpl.load(DeployerImpl.java:101) > at > org.apache.tuscany.core.deployer.DeployerImpl.deploy(DeployerImpl.java:76) > at > org.apache.tuscany.core.runtime.AbstractRuntime.deployApplicationScdl(AbstractRuntime.java:136) > at > org.apache.tuscany.runtime.standalone.host.StandaloneRuntimeImpl.initialize(StandaloneRuntimeImpl.java:85) > at > org.apache.tuscany.launcher.MainLauncherBooter.main(MainLauncherBooter.java:80) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-860) Launder should produce some meanlingful error messages instead of runtime exception
[ http://issues.apache.org/jira/browse/TUSCANY-860?page=all ] Jeremy Boynes closed TUSCANY-860. - Fix Version/s: Java-Mx (was: Java-M2) Resolution: Fixed Assignee: Jeremy Boynes > Launder should produce some meanlingful error messages instead of runtime > exception > --- > > Key: TUSCANY-860 > URL: http://issues.apache.org/jira/browse/TUSCANY-860 > Project: Tuscany > Issue Type: Bug > Components: Java SCA Core >Affects Versions: Java-M2 >Reporter: Raymond Feng > Assigned To: Jeremy Boynes >Priority: Minor > Fix For: Java-Mx > > > if I forget to pass the app jar to the launcher, I got > IndexOutOfBoundsException instead of a meaningful msg and if there's no > Main-Class entry in the manifest, I got NPE -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-867) DAS M2 Branch updates
[ http://issues.apache.org/jira/browse/TUSCANY-867?page=comments#action_12443136 ] Jeremy Boynes commented on TUSCANY-867: --- I applied this patch (sans bat script" and still have SNAPSHOT references in the project tree: $ grep -ri --exclude="*.svn-base" snapshot . ./BUILDING.txt: 1.If the mvn command completed successfully, you will see BUILD SUCCESSFUL in the output and tuscany-das-rdb-1.0-SNAPSHOT.jar is created under /java/das/rdb/target directory. ./BUILDING.txt:* sdo-api-r2.0.1-1.0-SNAPSHOT.jar - SDO 2.0 Interfaces ./BUILDING.txt:* tuscany-sdo-impl-1.0-SNAPSHOT.jar - SDO 2.0 implementation ./BUILDING.txt:* emf-common-2.2.0-SNAPSHOT.jar - some common framework utility and base classes ./BUILDING.txt:* emf-ecore-2.2.0-SNAPSHOT.jar - the EMF core runtime implementation classes (the Ecore metamodel) ./BUILDING.txt:* emf-ecore-change-2.2.0-SNAPSHOT.jar - the EMF change recorder and framework ./BUILDING.txt:* emf-ecore-xmi-2.2.0-SNAPSHOT.jar - EMF's default XML (and XMI) serializer and loader ./BUILDING.txt:* xsd-2.2.0-SNAPSHOT.jar - the XML Schema model ./distribution/binary/pom.xml:2.2-SNAPSHOT ./distribution/samples/pom.xml:2.2-SNAPSHOT ./pom.xml:apache.snapshots ./pom.xml:Apache Snapshot Repository ./pom.xml: http://people.apache.org/repo/m2-snapshot-repository ./pom.xml: ./pom.xml: ./pom.xml: ./pom.xml: ./samples/companyweb/readme.htm: class=SpellE>companyweb-xxx.war (e.g. sample-companyweb-1.0-incubator-M2-SNAPSHOT.war) > DAS M2 Branch updates > - > > Key: TUSCANY-867 > URL: http://issues.apache.org/jira/browse/TUSCANY-867 > Project: Tuscany > Issue Type: Improvement >Affects Versions: Java-M2 >Reporter: Luciano Resende > Assigned To: Luciano Resende >Priority: Blocker > Fix For: Java-M2 > > Attachments: tuscany867-take1.lresende.20061017.txt, > tuscany867-take2.lresende.20061017.txt > > > Need to add/update some files before cuting das tag. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (TUSCANY-733) Version information should not be in war plugin source code
[ http://issues.apache.org/jira/browse/TUSCANY-733?page=all ] Jeremy Boynes reassigned TUSCANY-733: - Assignee: Jeremy Boynes (was: Meeraj Kunnumpurath) > Version information should not be in war plugin source code > --- > > Key: TUSCANY-733 > URL: http://issues.apache.org/jira/browse/TUSCANY-733 > Project: Tuscany > Issue Type: Bug > Components: Maven Plugins >Affects Versions: Java-M2 >Reporter: Jeremy Boynes > Assigned To: Jeremy Boynes > Fix For: Java-M2 > > Attachments: tuscany-773.patch > > > The version of the runtime to use should be a configuration property of the > war plugin and not hard coded in Dependency. > Ideally, the default value for runtime version should come from a POM > property, perhaps the version of the POM plugin itself. A user of the plugin > should be able to override this in their own project with a configuration > property -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-733) Version information should not be in war plugin source code
[ http://issues.apache.org/jira/browse/TUSCANY-733?page=comments#action_12443530 ] Jeremy Boynes commented on TUSCANY-733: --- Patch applied to trunk - thanks JoJo > Version information should not be in war plugin source code > --- > > Key: TUSCANY-733 > URL: http://issues.apache.org/jira/browse/TUSCANY-733 > Project: Tuscany > Issue Type: Bug > Components: Maven Plugins >Affects Versions: Java-M2 >Reporter: Jeremy Boynes > Assigned To: Jeremy Boynes > Fix For: Java-M2 > > Attachments: tuscany-773.patch > > > The version of the runtime to use should be a configuration property of the > war plugin and not hard coded in Dependency. > Ideally, the default value for runtime version should come from a POM > property, perhaps the version of the POM plugin itself. A user of the plugin > should be able to override this in their own project with a configuration > property -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-949) Incorrect set of extensions published to the maven repo
[ http://issues.apache.org/jira/browse/TUSCANY-949?page=comments#action_12454069 ] Jeremy Boynes commented on TUSCANY-949: --- I don't think we should use profiles in this way. We already use profiles (e.g. in SDO) to determine the type of content that gets built (e.g. in SDO we use them to generate aggregated vs. non-aggregated javadoc, in SCA we have a sourcecheck profile that enables checkstyle and pmd) but this is using them to determine which modules get built. I don't think this allows us to do something like run sourcecheck on the release modules for example. This is really just trying to get modularity without doing the modularity work. It would be better to do that by restructuring the build into an appropriately modular tree. > Incorrect set of extensions published to the maven repo > --- > > Key: TUSCANY-949 > URL: http://issues.apache.org/jira/browse/TUSCANY-949 > Project: Tuscany > Issue Type: Bug > Components: Build System >Affects Versions: Java-M2 > Environment: all >Reporter: Simon Nash > Attachments: jira949.diff > > > mvn deploy publishes a number of extensions to the maven repo that should > not be published there because they are not fully tested and endorsed parts > of the Tuscany M2 release. Specifically, the following jars should not be > published: > groovy-1.0-incubator-M2.jar > databinding-castor-1.0-incubator-M2.jar > databinding-jaxb-1.0-incubator-M2.jar > databinding-xmlbeans-1.0-incubator-M2.jar > databinding-test-1.0-incubator-M2.jar > celtix-1.0-incubator-M2.jar > binding-jsonrpc-1.0-incubator-M2.jar > An option should be provided on the build to selectively publish only those > extensions that have been endorsed as part of the Tuscany M2 release. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-862) NPE when doing CurrentCompositeContext.locateService on a reference which uses interface.wsdl
[ http://issues.apache.org/jira/browse/TUSCANY-862?page=all ] Jeremy Boynes updated TUSCANY-862: -- Fix Version/s: Java-Mx (was: Java-M2) Big enough change that it's probably too much for M2 > NPE when doing CurrentCompositeContext.locateService on a reference which > uses interface.wsdl > - > > Key: TUSCANY-862 > URL: http://issues.apache.org/jira/browse/TUSCANY-862 > Project: Tuscany > Issue Type: Bug > Components: Java SCA Core >Affects Versions: Java-M2 >Reporter: ant elder > Assigned To: Jeremy Boynes > Fix For: Java-Mx > > > If you do CurrentCompositeContext.locateService on a reference which uses > interface.wsdl you get a NPE: > java.lang.NullPointerException > at > org.apache.tuscany.core.wire.jdk.JDKWireService.createProxy(JDKWireService.java:92) > at > org.apache.tuscany.spi.extension.ReferenceExtension.getServiceInstance(ReferenceExtension.java:81) > at > org.apache.tuscany.spi.extension.CompositeComponentExtension.locateService(CompositeComponentExtension.java:275) > at > org.apache.tuscany.core.launcher.CompositeContextImpl.locateService(CompositeContextImpl.java:65) > at helloworld.HelloWorldWSClient.setUp(HelloWorldWSClient.java:46) > Thats becuase the wire.getServiceContract().getInterfaceClass() returns null. > To demonstrate change the helloworldwsclient to use the reference > 'HelloWorldService' > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (TUSCANY-862) NPE when doing CurrentCompositeContext.locateService on a reference which uses interface.wsdl
[ http://issues.apache.org/jira/browse/TUSCANY-862?page=all ] Jeremy Boynes reassigned TUSCANY-862: - Assignee: Jeremy Boynes > NPE when doing CurrentCompositeContext.locateService on a reference which > uses interface.wsdl > - > > Key: TUSCANY-862 > URL: http://issues.apache.org/jira/browse/TUSCANY-862 > Project: Tuscany > Issue Type: Bug > Components: Java SCA Core >Affects Versions: Java-M2 >Reporter: ant elder > Assigned To: Jeremy Boynes > Fix For: Java-Mx > > > If you do CurrentCompositeContext.locateService on a reference which uses > interface.wsdl you get a NPE: > java.lang.NullPointerException > at > org.apache.tuscany.core.wire.jdk.JDKWireService.createProxy(JDKWireService.java:92) > at > org.apache.tuscany.spi.extension.ReferenceExtension.getServiceInstance(ReferenceExtension.java:81) > at > org.apache.tuscany.spi.extension.CompositeComponentExtension.locateService(CompositeComponentExtension.java:275) > at > org.apache.tuscany.core.launcher.CompositeContextImpl.locateService(CompositeContextImpl.java:65) > at helloworld.HelloWorldWSClient.setUp(HelloWorldWSClient.java:46) > Thats becuase the wire.getServiceContract().getInterfaceClass() returns null. > To demonstrate change the helloworldwsclient to use the reference > 'HelloWorldService' > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1000) Components do not support multiple services
[
http://issues.apache.org/jira/browse/TUSCANY-1000?page=comments#action_12459432
]
Jeremy Boynes commented on TUSCANY-1000:
This should happen if you do not specify componentName/serviceName in the call
to locateService.
Please could you attach the code where you make that call (showing the name
passed in).
> Components do not support multiple services
> ---
>
> Key: TUSCANY-1000
> URL: http://issues.apache.org/jira/browse/TUSCANY-1000
> Project: Tuscany
> Issue Type: Bug
>Affects Versions: Java-M2
>Reporter: Lou Amodeo
>
> I have a component that implements multiple service interfaces at runtime the
> locateService() receives an exception indicating that components can only
> have 1 service. The C&I spec states that a component can declare using
> @Service an array of interfaces.
> @Service(interfaces={ConversationsClient.class,ConversationsClient2.class})
> public class ConversationsClientImpl implements ConversationsClient,
> ConversationsClient2, ConversationsCallback {
> ---
> Test set: org.apache.tuscany.sca.test.ConversationsITest
> ---
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.02 sec <<<
> FAILURE!
> testCallBackSetCallback(org.apache.tuscany.sca.test.ConversationsITest) Time
> elapsed: 0 sec <<< ERROR!
> org.apache.tuscany.spi.component.TargetException: Component must have exactly
> one service
> at
> org.apache.tuscany.core.implementation.java.JavaAtomicComponent.getServiceInstance(JavaAtomicComponent.java:72)
> at
> org.apache.tuscany.spi.extension.CompositeComponentExtension.locateService(CompositeComponentExtension.java:268)
> at
> org.apache.tuscany.core.launcher.CompositeContextImpl.locateService(CompositeContextImpl.java:65)
> at
> org.apache.tuscany.sca.test.ConversationsITest.setUp(ConversationsITest.java:17)
> at junit.framework.TestCase.runBare(TestCase.java:125)
> at junit.framework.TestResult$1.protect(TestResult.java:106)
> at junit.framework.TestResult.runProtected(TestResult.java:124)
> at junit.framework.TestResult.run(TestResult.java:109)
> at junit.framework.TestCase.run(TestCase.java:118)
> at junit.framework.TestSuite.runTest(TestSuite.java:208)
> at junit.framework.TestSuite.run(TestSuite.java:203)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:615)
> at
> org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:210)
> at
> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:135)
> at
> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:122)
> at
> org.apache.tuscany.sca.plugin.itest.TuscanyITestMojo.run(TuscanyITestMojo.java:122)
> at
> org.apache.tuscany.sca.plugin.itest.TuscanyITestMojo.runSurefire(TuscanyITestMojo.java:88)
> at
> org.apache.tuscany.sca.plugin.itest.TuscanyITestMojo.execute(TuscanyITestMojo.java:77)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:256)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:615)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
>
[jira] Created: (TUSCANY-1028) Autowire should support all compatible services interfaces in class hierarchy
Autowire should support all compatible services interfaces in class hierarchy - Key: TUSCANY-1028 URL: https://issues.apache.org/jira/browse/TUSCANY-1028 Project: Tuscany Issue Type: Bug Reporter: Jeremy Boynes Assigned To: Jeremy Boynes When a component registers as an autowire target other components should be able to autowire to is using any super-interface rather than just the interface it registers with. For example, if X1 extends X and a component offers service X1 then it should be a valid target for clients with X references. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-1066) Failing to run samples with Standalone distributions : Unable to locate profile directory
[ https://issues.apache.org/jira/browse/TUSCANY-1066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Boynes resolved TUSCANY-1066. Resolution: Won't Fix This should work with just the runtime/standalone assembly. We should remove the old distribution. > Failing to run samples with Standalone distributions : Unable to locate > profile directory > - > > Key: TUSCANY-1066 > URL: https://issues.apache.org/jira/browse/TUSCANY-1066 > Project: Tuscany > Issue Type: Bug > Components: Java SCA Core >Affects Versions: Java-SCA-M3 >Reporter: Luciano Resende > Fix For: Java-SCA-M3 > > > Build a distribution and try to run standalone sample calculator > Exception in thread "main" java.io.FileNotFoundException: Unable to locate > profile directory: d:\temp\sca_standalone_distribution\profiles\launcher > at > org.apache.tuscany.runtime.standalone.DirectoryHelper.getProfileDirectory(DirectoryHelper.java:124) > at org.apache.tuscany.launcher.Main.createRuntimeInfo(Main.java:89) > at org.apache.tuscany.launcher.Main.main(Main.java:56) > Workaround : > build : java/sca/runtime/standalone/assembly > then overlap the generated zip in the standalone distribution -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-1028) Autowire should support all compatible services interfaces in class hierarchy
[ https://issues.apache.org/jira/browse/TUSCANY-1028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Boynes resolved TUSCANY-1028. Resolution: Fixed This is fixed although the solution is not very elegant. > Autowire should support all compatible services interfaces in class hierarchy > - > > Key: TUSCANY-1028 > URL: https://issues.apache.org/jira/browse/TUSCANY-1028 > Project: Tuscany > Issue Type: Bug >Reporter: Jeremy Boynes > Assigned To: Jeremy Boynes > Fix For: Java-SCA-M3 > > > When a component registers as an autowire target other components should be > able to autowire to is using any super-interface rather than just the > interface it registers with. For example, if X1 extends X and a component > offers service X1 then it should be a valid target for clients with X > references. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1069) Cannot access default service of a component implemented by a composite using locateService
Cannot access default service of a component implemented by a composite using locateService --- Key: TUSCANY-1069 URL: https://issues.apache.org/jira/browse/TUSCANY-1069 Project: Tuscany Issue Type: Bug Components: Java SCA Core Reporter: Jeremy Boynes If the "port" part of the name supplied to locateService(Class, String) is empty then the class name of the supplied service is used. There is no guarantee that the composite has a single exposed service with that name. If the port name is null then we need to check that the component just has one exposed service and use that regardless of it's name. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (TUSCANY-1039) axis binding is requiring javax/servlet/Servlet in standalone launcher geting noclassdefFoundError
[ https://issues.apache.org/jira/browse/TUSCANY-1039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Boynes reopened TUSCANY-1039: Assignee: Rick Rineholt Reopening as we need to remove the workaround from the assembly before we release the runtime > axis binding is requiring javax/servlet/Servlet in standalone launcher geting > noclassdefFoundError > -- > > Key: TUSCANY-1039 > URL: https://issues.apache.org/jira/browse/TUSCANY-1039 > Project: Tuscany > Issue Type: Bug > Components: Java SCA Core >Affects Versions: Java-SCA-M3 >Reporter: Rick Rineholt > Assigned To: Rick Rineholt > > axis binding is requiring javax/servlet/Servlet in standalone launcher geting > noclassdefFoundError > This was fixed a few days ago ... seems to be back again. -- 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-1039) axis binding is requiring javax/servlet/Servlet in standalone launcher geting noclassdefFoundError
[ https://issues.apache.org/jira/browse/TUSCANY-1039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Boynes updated TUSCANY-1039: --- Priority: Blocker (was: Major) > axis binding is requiring javax/servlet/Servlet in standalone launcher geting > noclassdefFoundError > -- > > Key: TUSCANY-1039 > URL: https://issues.apache.org/jira/browse/TUSCANY-1039 > Project: Tuscany > Issue Type: Bug > Components: Java SCA Core >Affects Versions: Java-SCA-M3 >Reporter: Rick Rineholt > Assigned To: Rick Rineholt >Priority: Blocker > > axis binding is requiring javax/servlet/Servlet in standalone launcher geting > noclassdefFoundError > This was fixed a few days ago ... seems to be back again. -- 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-1114) Unable to download resource from repository on build
[ https://issues.apache.org/jira/browse/TUSCANY-1114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12473217 ] Jeremy Boynes commented on TUSCANY-1114: This POM is also included in the samples distribution so "mvn -N" from the root of that distribution will install it locally for you. > Unable to download resource from repository on build > > > Key: TUSCANY-1114 > URL: https://issues.apache.org/jira/browse/TUSCANY-1114 > Project: Tuscany > Issue Type: Bug > Components: Java SCA Samples >Affects Versions: Java-M2 > Environment: WinXP >Reporter: Justin Stewart > > Just downloaded and installed SCA Java M2 release - binary and samples. > When building the calculator sample using Maven, I get: > $ mvn > [INFO] Scanning for projects... > Downloading: > http://repo1.maven.org/maven2/org/apache/tuscany/sca/samples/parent > /1.0-incubator-M2/parent-1.0-incubator-M2.pom > [WARNING] Unable to get resource from repository central > (http://repo1.maven.org > /maven2) > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] Error building POM (may not be this project's POM). > ... > Sure enough, > http://repo1.maven.org/maven2/org/apache/tuscany/sca/samples/parent > /1.0-incubator-M2/parent-1.0-incubator-M2.pom doesn't exist. > Thanks, > Justin -- 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-1002) When redefining sdoModel.xsd in XSDHelperImpl, special ChangeSummaryType must be preloaded
[ https://issues.apache.org/jira/browse/TUSCANY-1002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Boynes updated TUSCANY-1002: --- Comment: was deleted > When redefining sdoModel.xsd in XSDHelperImpl, special ChangeSummaryType must > be preloaded > -- > > Key: TUSCANY-1002 > URL: https://issues.apache.org/jira/browse/TUSCANY-1002 > Project: Tuscany > Issue Type: Bug > Components: Java SDO Implementation >Affects Versions: Java-SDO-Mx >Reporter: Frank Budinsky >Priority: Minor > Fix For: Java-SDO-Mx > > > Currently there is a temporary hack in datagraph.xsd (in sdo-api project) to > allow us to regenerate sdoModel.xsd with the proper ChangeSummaryType > behavior. We need to: > 1. Remove the temporary hack in datagraph.xsd which is redefining > ChangeSummaryType to be a simple type - i.e., put it back to the way it was > defined in the spec. > 2. Add code in XSDHelperImpl ctor to preload the special ChangeSummaryType > (which is defined in impl/src/main/resources/xml/sdoModelChangeSummary.xsd) > when redefineBuiltIn.equals(ModelFactoryImpl,NAMESPACE_URI). > With these changes, we will be working as the spec says: The definition of > ChangeSummaryType is a complex type in XML (datagraph.xsd), but is treated as > a simple data type at the model level. -- 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-826) Containment cycle should result in Exception
[ https://issues.apache.org/jira/browse/TUSCANY-826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Boynes updated TUSCANY-826: -- Comment: was deleted > Containment cycle should result in Exception > > > Key: TUSCANY-826 > URL: https://issues.apache.org/jira/browse/TUSCANY-826 > Project: Tuscany > Issue Type: Bug > Components: Java SDO Implementation >Affects Versions: Java-SDO-Mx > Environment: Windows XP, both Sun and IBM JVMs >Reporter: Brian Murray > Fix For: Java-SDO-Mx > > Attachments: ContainmentCycle.patch, ContainmentCycleError.java, > ContainmentTest.zip > > > Near the bottom of page 19 in the 2.0.1 specification it is stated that > "Containment cannot have cycles. If a set or add would create a containment > cycle an exception is thrown." > However, I have found that no such exception is thrown. I will attach a test > case showing the creation of (and the potential to infinitely loop through) a > containment cycle. -- 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] Closed: (TUSCANY-192) intermittent build failure: java.lang.IllegalArgumentException: wrong number of arguments
[ http://issues.apache.org/jira/browse/TUSCANY-192?page=all ] Jeremy Boynes closed TUSCANY-192: - Resolution: Invalid Closed at Raymond's request > intermittent build failure: java.lang.IllegalArgumentException: wrong number > of arguments > -- > > Key: TUSCANY-192 > URL: http://issues.apache.org/jira/browse/TUSCANY-192 > Project: Tuscany > Type: Bug > Components: Java SCA Axis Integration > Reporter: Raymond Feng > > [java.lang.IllegalArgumentException: wrong number of arguments > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. > java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces > sorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at > org.apache.tuscany.container.java.invocation.AbstractJavaComponentInv > oker.invokeTarget(AbstractJavaComponentInvoker.java:58) > at > org.apache.tuscany.container.java.invocation.AbstractJavaComponentInv > oker.invoke(AbstractJavaComponentInvoker.java:67) > at > org.apache.tuscany.binding.axis2.builder.WebServiceEntryPointBuilder$ > EntryPointInvokerInterceptor.invoke(WebServiceEntryPointBuilder.java:160) > at > org.apache.tuscany.core.invocation.jdk.JDKInvocationHandler.invoke(JD > KInvocationHandler.java:120) > at > org.apache.tuscany.binding.axis2.handler.WebServiceEntryPointInOutSyn > cMessageReceiver.invokeBusinessLogic(WebServiceEntryPointInOutSyncMessageReceive > r.java:88) > at > org.apache.axis2.receivers.AbstractInOutSyncMessageReceiver.receive(A > bstractInOutSyncMessageReceiver.java:37) > at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:408) > at > org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostReq > uest(HTTPTransportUtils.java:288) > at > org.apache.axis2.transport.http.AxisServlet.doPost(AxisServlet.java:1 > 60) > at > org.apache.tuscany.binding.axis2.handler.WebServiceEntryPointServlet. > doPost(WebServiceEntryPointServlet.java:235) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:763) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:856) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl > icationFilterChain.java:252) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF > ilterChain.java:173) > at > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperV > alve.java:213) > at > org.apache.catalina.core.StandardContextValve.invoke(StandardContextV > alve.java:178) > at org.apache.tuscany.tomcat.TuscanyValve.invoke(TuscanyValve.java:87) > at > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.j > ava:126) > at > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.j > ava:105) > at > org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:869) > at > org.apache.tuscany.tomcat.integration.TomcatIntegrationTestCase.testW > ebServiceIntegration(TomcatIntegrationTestCase.java:92) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. > java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces > sorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at junit.framework.TestCase.runTest(TestCase.java:154) > at junit.framework.TestCase.runBare(TestCase.java:127) > at junit.framework.TestResult$1.protect(TestResult.java:106) > at junit.framework.TestResult.runProtected(TestResult.java:124) > at junit.framework.TestResult.run(TestResult.java:109) > at junit.framework.TestCase.run(TestCase.java:118) > at junit.framework.TestSuite.runTest(TestSuite.java:208) > at junit.framework.TestSuite.run(TestSuite.java:203) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. > java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces > sorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at > org.apache.maven.surefire.battery.JUnitBattery.executeJUnit(JUnitBatt > ery.java:242) > at > org.apache.maven.surefire.battery.JUnitBattery.execute(JUnitBattery.j > ava:216) > at > org.apache.maven.surefire.Surefire.executeBattery(Surefire.java:215) > at org.apache.maven.surefire.Surefire.run(Surefire.java:163) > at org.apache.maven.surefire.Surefire.run(Suref
[jira] Created: (TUSCANY-200) Default scope for system components should be MODULE not INSTANCE
Default scope for system components should be MODULE not INSTANCE - Key: TUSCANY-200 URL: http://issues.apache.org/jira/browse/TUSCANY-200 Project: Tuscany Type: Bug Components: Java SCA Core Reporter: Jeremy Boynes Assigned to: Jim Marino The default scope for system components is currently INSTANCE but the typical usage is model -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (TUSCANY-200) Default scope for system components should be MODULE not INSTANCE
[ http://issues.apache.org/jira/browse/TUSCANY-200?page=comments#action_12374764 ] Jeremy Boynes commented on TUSCANY-200: --- Jim started to make this change in r394333 but that only impacts the builder. During loading, introspection on the class explicitly sets the scope to INSTANCE > Default scope for system components should be MODULE not INSTANCE > - > > Key: TUSCANY-200 > URL: http://issues.apache.org/jira/browse/TUSCANY-200 > Project: Tuscany > Type: Bug > Components: Java SCA Core > Reporter: Jeremy Boynes > Assignee: Jim Marino > > The default scope for system components is currently INSTANCE but the typical > usage is model -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TUSCANY-200) Default scope for system components should be MODULE not INSTANCE
[ http://issues.apache.org/jira/browse/TUSCANY-200?page=all ] Jeremy Boynes updated TUSCANY-200: -- Description: The default scope for system components is currently INSTANCE but the typical usage is module (was: The default scope for system components is currently INSTANCE but the typical usage is model) > Default scope for system components should be MODULE not INSTANCE > - > > Key: TUSCANY-200 > URL: http://issues.apache.org/jira/browse/TUSCANY-200 > Project: Tuscany > Type: Bug > Components: Java SCA Core > Reporter: Jeremy Boynes > Assignee: Jim Marino > > The default scope for system components is currently INSTANCE but the typical > usage is module -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (TUSCANY-201) Allow extensions to WSDL processing
Allow extensions to WSDL processing --- Key: TUSCANY-201 URL: http://issues.apache.org/jira/browse/TUSCANY-201 Project: Tuscany Type: Improvement Components: Java SCA Core Reporter: Jeremy Boynes Assigned to: Jeremy Boynes Allow extension code to customize the WSDL ExtensionRegistry to handle WSDL extensions -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TUSCANY-201) Allow extensions to WSDL processing
[ http://issues.apache.org/jira/browse/TUSCANY-201?page=all ] Jeremy Boynes updated TUSCANY-201: -- Attachment: wsdl_patch Attached patch originally sent to mailing list by Dan Kulp > Allow extensions to WSDL processing > --- > > Key: TUSCANY-201 > URL: http://issues.apache.org/jira/browse/TUSCANY-201 > Project: Tuscany > Type: Improvement > Components: Java SCA Core > Reporter: Jeremy Boynes > Assignee: Jeremy Boynes > Attachments: wsdl_patch > > Allow extension code to customize the WSDL ExtensionRegistry to handle WSDL > extensions -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TUSCANY-201) Allow extensions to WSDL processing
[ http://issues.apache.org/jira/browse/TUSCANY-201?page=all ] Jeremy Boynes updated TUSCANY-201: -- Attachment: (was: wsdl_patch) > Allow extensions to WSDL processing > --- > > Key: TUSCANY-201 > URL: http://issues.apache.org/jira/browse/TUSCANY-201 > Project: Tuscany > Type: Improvement > Components: Java SCA Core > Reporter: Jeremy Boynes > Assignee: Jeremy Boynes > Attachments: wsdl_patch > > Allow extension code to customize the WSDL ExtensionRegistry to handle WSDL > extensions -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (TUSCANY-201) Allow extensions to WSDL processing
[ http://issues.apache.org/jira/browse/TUSCANY-201?page=comments#action_12374829 ] Jeremy Boynes commented on TUSCANY-201: --- The InterfaceWSDLLoader has been modified to intialize portType information using the WSDLDefinitionRegistry so these extensions should be available there. > Allow extensions to WSDL processing > --- > > Key: TUSCANY-201 > URL: http://issues.apache.org/jira/browse/TUSCANY-201 > Project: Tuscany > Type: Improvement > Components: Java SCA Core > Reporter: Jeremy Boynes > Assignee: Jeremy Boynes > Attachments: wsdl_patch > > Allow extension code to customize the WSDL ExtensionRegistry to handle WSDL > extensions -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (TUSCANY-208) Fix eclipse warnings for sca/bindings/bindings.axis2
[ http://issues.apache.org/jira/browse/TUSCANY-208?page=all ] Jeremy Boynes reassigned TUSCANY-208: - Assign To: Jeremy Boynes (was: ant elder) > Fix eclipse warnings for sca/bindings/bindings.axis2 > > > Key: TUSCANY-208 > URL: http://issues.apache.org/jira/browse/TUSCANY-208 > Project: Tuscany > Type: Improvement > Reporter: Daniel Kulp > Assignee: Jeremy Boynes > Priority: Minor > Attachments: axis2_patch > > FIx all eclipse warnings in bindings.axis2. Also make it 99% compliant with > the checkstyle and pmd rules included in the celtix patch. > To fix many of the warnings, I had to propertly "type" all the collections as > well as use generics in a few other areas. Thus, the patch is a bit more > than just reformatting and general cleanup. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (TUSCANY-206) Implement Celtix WS Binding
[ http://issues.apache.org/jira/browse/TUSCANY-206?page=all ] Jeremy Boynes reassigned TUSCANY-206: - Assign To: Jeremy Boynes (was: Daniel Kulp) > Implement Celtix WS Binding > --- > > Key: TUSCANY-206 > URL: http://issues.apache.org/jira/browse/TUSCANY-206 > Project: Tuscany > Type: New Feature > Components: Java SCA Common > Reporter: Daniel Kulp > Assignee: Jeremy Boynes > Attachments: binding.celtix.tar.gz, sunjars.tar.gz > > Issue to track the patches and stuff related to creating a Celtix based ws > binding. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (TUSCANY-209) Fix more eclipse warnings for sca/model
[ http://issues.apache.org/jira/browse/TUSCANY-209?page=all ] Jeremy Boynes closed TUSCANY-209: - Resolution: Fixed Applied patch. I assume Eclipse is still happy but IDEA complains (serialUID, non-static inner classes, ArrayList.remove(), complexity of CompositeImpl.initialize()) > Fix more eclipse warnings for sca/model > --- > > Key: TUSCANY-209 > URL: http://issues.apache.org/jira/browse/TUSCANY-209 > Project: Tuscany > Type: Improvement > Reporter: Daniel Kulp > Assignee: Jeremy Boynes > Priority: Trivial > Attachments: sca_model.patch > > Small patch to fix some eclipse (and -Xlint) warnings in the model package > that were recently introduced. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (TUSCANY-208) Fix eclipse warnings for sca/bindings/bindings.axis2
[ http://issues.apache.org/jira/browse/TUSCANY-208?page=all ] Jeremy Boynes closed TUSCANY-208: - Resolution: Fixed Patch applied > Fix eclipse warnings for sca/bindings/bindings.axis2 > > > Key: TUSCANY-208 > URL: http://issues.apache.org/jira/browse/TUSCANY-208 > Project: Tuscany > Type: Improvement > Reporter: Daniel Kulp > Assignee: Jeremy Boynes > Priority: Minor > Attachments: axis2_patch > > FIx all eclipse warnings in bindings.axis2. Also make it 99% compliant with > the checkstyle and pmd rules included in the celtix patch. > To fix many of the warnings, I had to propertly "type" all the collections as > well as use generics in a few other areas. Thus, the patch is a bit more > than just reformatting and general cleanup. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (TUSCANY-206) Implement Celtix WS Binding
[ http://issues.apache.org/jira/browse/TUSCANY-206?page=comments#action_12375224 ] Jeremy Boynes commented on TUSCANY-206: --- Patches applied to create projects in the sandbox under celtix > Implement Celtix WS Binding > --- > > Key: TUSCANY-206 > URL: http://issues.apache.org/jira/browse/TUSCANY-206 > Project: Tuscany > Type: New Feature > Components: Java SCA Common > Reporter: Daniel Kulp > Assignee: Jeremy Boynes > Attachments: binding.celtix.tar.gz, sunjars.tar.gz > > Issue to track the patches and stuff related to creating a Celtix based ws > binding. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (TUSCANY-219) @Property on a setter method does not work
[ http://issues.apache.org/jira/browse/TUSCANY-219?page=all ]
Jeremy Boynes reassigned TUSCANY-219:
-
Assign To: Jim Marino
Should go away when Jim changes the annotation introspector but assigning it to
him so he does not forget.
> @Property on a setter method does not work
> --
>
> Key: TUSCANY-219
> URL: http://issues.apache.org/jira/browse/TUSCANY-219
> Project: Tuscany
> Type: Bug
> Components: Java SCA Core
> Reporter: Jean-Sebastien Delfino
> Assignee: Jim Marino
>
> This is a significant problem as following the recommended practice for
> JavaBean properties causes an exception.
> To reproduce the problem, modify
> org.apache.tuscany.samples.helloworldmc.HelloWorldServiceComponentImpl as
> follows:
> private String greetingMiddle;
>
> @Property
> public void setGreetingMiddle(String greetingMiddle) {
> this.greetingMiddle = greetingMiddle;
> }
>
> public String getGreetingMiddle() {
> return greetingMiddle;
> }
> run mvn from helloworldmc.
> Here's the surefire report:
> ---
> Battery:
> org.apache.tuscany.samples.helloworldmc.HelloWorldServiceComponentTestCase
> ---
> Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 1.034 sec
> testGeetings(org.apache.tuscany.samples.helloworldmc.HelloWorldServiceComponentTestCase)
> Time elapsed: 1.008 sec <<< ERROR!
> [ stdout ] ---
> [ stderr ] ---
> [ stacktrace ] ---
> org.apache.tuscany.core.config.InvalidSetterException: public void
> org.apache.tuscany.samples.helloworldmc.HelloWorldServiceComponentImpl.setGreetingMiddle(java.lang.String)
> at
> org.apache.tuscany.core.config.impl.Java5ComponentTypeIntrospector.addProperty(Java5ComponentTypeIntrospector.java:332)
> at
> org.apache.tuscany.core.config.impl.Java5ComponentTypeIntrospector.introspectPublicMethods(Java5ComponentTypeIntrospector.java:288)
> at
> org.apache.tuscany.core.config.impl.Java5ComponentTypeIntrospector.introspectAnnotatedMembers(Java5ComponentTypeIntrospector.java:201)
> at
> org.apache.tuscany.core.config.impl.Java5ComponentTypeIntrospector.introspect(Java5ComponentTypeIntrospector.java:80)
> at
> org.apache.tuscany.container.java.loader.JavaImplementationLoader.loadComponentTypeByIntrospection(JavaImplementationLoader.java:119)
> at
> org.apache.tuscany.container.java.loader.JavaImplementationLoader.loadComponentType(JavaImplementationLoader.java:112)
> at
> org.apache.tuscany.container.java.loader.JavaImplementationLoader.load(JavaImplementationLoader.java:91)
> at
> org.apache.tuscany.container.java.loader.JavaImplementationLoader.load(JavaImplementationLoader.java:51)
> at
> org.apache.tuscany.core.loader.impl.StAXLoaderRegistryImpl.load(StAXLoaderRegistryImpl.java:64)
> at
> org.apache.tuscany.core.loader.assembly.ComponentLoader.load(ComponentLoader.java:80)
> at
> org.apache.tuscany.core.loader.assembly.ComponentLoader.load(ComponentLoader.java:53)
> at
> org.apache.tuscany.core.loader.impl.StAXLoaderRegistryImpl.load(StAXLoaderRegistryImpl.java:64)
> at
> org.apache.tuscany.core.loader.assembly.AggregateLoader.loadAggregate(AggregateLoader.java:43)
> at
> org.apache.tuscany.core.loader.assembly.ModuleLoader.load(ModuleLoader.java:39)
> at
> org.apache.tuscany.core.loader.assembly.ModuleLoader.load(ModuleLoader.java:32)
> at
> org.apache.tuscany.core.loader.impl.StAXLoaderRegistryImpl.load(StAXLoaderRegistryImpl.java:64)
> at
> org.apache.tuscany.core.config.impl.StAXModuleComponentConfigurationLoaderImpl.loadModule(StAXModuleComponentConfigurationLoaderImpl.java:51)
> at
> org.apache.tuscany.core.config.impl.AbstractModuleComponentConfigurationLoader.loadModuleComponent(AbstractModuleComponentConfigurationLoader.java:98)
> at
> org.apache.tuscany.core.config.impl.AbstractModuleComponentConfigurationLoader.loadModuleComponent(AbstractModuleComponentConfigurationLoader.java:88)
> at
> org.apache.tuscany.core.config.impl.AbstractModuleComponentConfigurationLoader.loadModuleComponent(AbstractModuleComponentConfigurationLoader.java:61)
> at
> org.apache.tuscany.core.client.TuscanyRuntime.(TuscanyRuntime.java:103)
> at
> org.apache.tuscany.core.client.TuscanyRuntime.(TuscanyRuntime.java:67)
> at
> org.apache.tuscany.samples.helloworldmc.HelloWorldServiceComponentTestCase.testGeetings(HelloWorldServiceComponentTestCase.java:30)
> at sun.reflect.NativeMethodAcces
[jira] Closed: (TUSCANY-141) interface.wsdl doesn't work in .componentType side files
[ http://issues.apache.org/jira/browse/TUSCANY-141?page=all ] Jeremy Boynes closed TUSCANY-141: - Closing as the import issue is fixed and the other problems are not related to the sidefile. > interface.wsdl doesn't work in .componentType side files > > > Key: TUSCANY-141 > URL: http://issues.apache.org/jira/browse/TUSCANY-141 > Project: Tuscany > Type: Bug > Components: Java SCA Core > Reporter: ant elder > Assignee: Jeremy Boynes > > Using interface.wsdl in .componentType side file fails as it can't find the > WSDL. > It looks like the import.wsdl doesn't get processed until after the side file > is processed. The JavaScript sample 7 can be used to recreate the problem, > look in HelloWorldImpl.componentType and there's a commented out > interface.wsdl, change to use that gives this exception: > java.lang.IllegalArgumentException: Cannot find WSDL definition for > http://helloworld.samples.tuscany.apache.org > at > org.apache.tuscany.model.types.wsdl.impl.WSDLServiceContractImpl.getPortType(WSDLServiceContractImpl.java:158) > at > org.apache.tuscany.model.types.wsdl.impl.WSDLServiceContractImpl.initialize(WSDLServiceContractImpl.java:103) > at > org.apache.tuscany.model.assembly.impl.PortImpl.initialize(PortImpl.java:77) > at > org.apache.tuscany.model.assembly.impl.ComponentTypeImpl.initialize(ComponentTypeImpl.java:117) > at > org.apache.tuscany.model.assembly.impl.ComponentImplementationImpl.initialize(ComponentImplementationImpl.java:62) > at > org.apache.tuscany.container.js.assembly.impl.JavaScriptImplementationImpl.initialize(JavaScriptImplementationImpl.java:73) > at > org.apache.tuscany.model.assembly.impl.ComponentImpl.initialize(ComponentImpl.java:115) > at > org.apache.tuscany.model.scdl.loader.impl.SCDLModelContentHandlerImpl$9.run(SCDLModelContentHandlerImpl.java:409) > at > org.apache.tuscany.model.util.ModelTransformerImpl.transformPass2(ModelTransformerImpl.java:122) > at > org.apache.tuscany.model.util.ModelTransformerImpl.transform(ModelTransformerImpl.java:42) > at > org.apache.tuscany.model.scdl.loader.impl.SCDLAssemblyModelLoaderImpl.transform(SCDLAssemblyModelLoaderImpl.java:198) > at > org.apache.tuscany.model.scdl.loader.impl.SCDLAssemblyModelLoaderImpl.loadModule(SCDLAssemblyModelLoaderImpl.java:107) > at > org.apache.tuscany.core.config.impl.ModuleComponentConfigurationLoaderImpl.loadModule(ModuleComponentConfigurationLoaderImpl.java:48) > at > org.apache.tuscany.core.config.impl.AbstractModuleComponentConfigurationLoader.loadModuleComponent(AbstractModuleComponentConfigurationLoader.java:98) > at > org.apache.tuscany.core.config.impl.AbstractModuleComponentConfigurationLoader.loadModuleComponent(AbstractModuleComponentConfigurationLoader.java:88) > at > org.apache.tuscany.core.config.impl.AbstractModuleComponentConfigurationLoader.loadModuleComponent(AbstractModuleComponentConfigurationLoader.java:61) > at > org.apache.tuscany.core.client.TuscanyRuntime.(TuscanyRuntime.java:100) > at > org.apache.tuscany.core.client.TuscanyRuntime.(TuscanyRuntime.java:64) > at sample.Sample7Client.invoke(Sample7Client.java:38) > at sample.Sample7TestCase.testGeetings(Sample7TestCase.java:28) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) > at java.lang.reflect.Method.invoke(Unknown Source) > at junit.framework.TestCase.runTest(TestCase.java:154) > at junit.framework.TestCase.runBare(TestCase.java:127) > at junit.framework.TestResult$1.protect(TestResult.java:106) > at junit.framework.TestResult.runProtected(TestResult.java:124) > at junit.framework.TestResult.run(TestResult.java:109) > at junit.framework.TestCase.run(TestCase.java:118) > at junit.framework.TestSuite.runTest(TestSuite.java:208) > at junit.framework.TestSuite.run(TestSuite.java:203) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:478) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:344) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (TUSCANY-43) Cannot autowire within module
[ http://issues.apache.org/jira/browse/TUSCANY-43?page=all ] Jeremy Boynes closed TUSCANY-43: Resolution: Fixed Fixed by jmarino's refactor of autowire > Cannot autowire within module > - > > Key: TUSCANY-43 > URL: http://issues.apache.org/jira/browse/TUSCANY-43 > Project: Tuscany > Type: Bug > Components: Java SCA Core > Reporter: Jeremy Boynes > > Autowire references between components in the same module do not work. Due to > chicken-egg issues a "org.apache.tuscany.core.builder.BuilderConfigException: > No autowire found for ..." exception is thrown during the build phase. > This occurs because the builder is being too aggressive in wiring by trying > to create a SingletonObjectFactory - instead, this should be deferred until > the component is started. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (TUSCANY-57) MonitorFactory should be a system service
[ http://issues.apache.org/jira/browse/TUSCANY-57?page=all ] Jeremy Boynes closed TUSCANY-57: Resolution: Fixed Injection of monitors is now directly supported > MonitorFactory should be a system service > - > > Key: TUSCANY-57 > URL: http://issues.apache.org/jira/browse/TUSCANY-57 > Project: Tuscany > Type: Bug > Components: Java SCA Core > Reporter: Jeremy Boynes > > The MonitorFactory should be a system service rather than part of the > RuntimeContext -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (TUSCANY-238) Unhelpful namespace for Tuscany schemata
Unhelpful namespace for Tuscany schemata Key: TUSCANY-238 URL: http://issues.apache.org/jira/browse/TUSCANY-238 Project: Tuscany Type: Bug Components: Java SCA Core Reporter: Jeremy Boynes We define XML namespaces with the URI beginning http://org.apache.tuscany/xmlns/... This is not resolvable to a web address. It would be better if we changed these to a valid FQDN http://tuscany.apache.org/xmlns/... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (TUSCANY-262) The packaging scheme for Tuscany runtime and dependency jars is problematic against the Tomcat class loading hierarchy
[ http://issues.apache.org/jira/browse/TUSCANY-262?page=comments#action_12377639 ] Jeremy Boynes commented on TUSCANY-262: --- In short, yes this is by design, at least of Tomcat and the integration code for it. Tomcat does this to create isolation between the classes and libraries it itself uses and those that the applications that it is running might use. This prevents classes from the container leaking in to an application's classpath and overriding versions that the application may want. It also prevents security problems caused by exposing the container's internals to applications or potential conflicts when static fields are used. The integration code follows Tomcat's classloading model and places the Tuscany implementation code in the container's classloading scope. The only classes that should be shared are the standard org.osoa interfaces (which are currently located in the common classloader just like the servlet API classes). One of the complexities of this scheme is that the container code does not have access to application classes using its own classloader. To address this, the J2EE programming model makes use of the Thread context classloader (TCCL) which allows the container to associate the application classloader with the currently running Thread before a request is handed over to application code. When the application calls back into the container, the container code can retrieve the application classloader from the Thread whenever it needs to access the application code. Application code should not need to access this classloader as it has access to its own using getClass().getClassLoader(); in fact, in a strict security environment, it will not even be able to access the TCCL (unless it happens to be the application classloader itself). Many of the problems we are seeing are because code is not making this separation between container and application classloaders a top level concept. For example, the SDO implementation always keys its type system off the TCCL which means that any time the container needs to interact with SDO it needs to ensure the TCCL is set to the application classloader. Moreover, due to the use of static initializers, it must set the TCCL every time it does anything that may touch an application class. The real solution here is for the libraries to provide mechanisms that allow operations to be performed by the container on behalf of the application using an explicitly provided classloader. Work has start on this with SDO, I am not sure what the situation is with Axis2. Placing all the Tuscany implementation on the application classpath by moving the jars to common will only cause greater problems in the long run and is not something that should be done. > The packaging scheme for Tuscany runtime and dependency jars is problematic > against the Tomcat class loading hierarchy > -- > > Key: TUSCANY-262 > URL: http://issues.apache.org/jira/browse/TUSCANY-262 > Project: Tuscany > Type: Bug > Components: Java SCA Tomcat Integration > Reporter: Raymond Feng > Priority: Critical > > As a result from the investigation on JIRA issue Tuscany-258, I found the > following problem. > Right now, most of the Tuscany and dependency jars are copied to > $CATALINA_HOME/server/lib. Is it by design? I think it's problematic and it's > the root cause of the problem > described by 258. > Here's a quote from the Tomcat 5.0 document @ > http://tomcat.apache.org/tomcat-5.0-doc/class-loader-howto.html: > "Catalina - This class loader is initialized to include all classes and > resources required to implement Tomcat 5 itself. These classes and resources > are TOTALLY invisible to web applications. All unpacked classes and resources > in $CATALINA_HOME/server/classes, as well as classes and resources in JAR > files under $CATALINA_HOME/server/lib, are made visible through this class > loader. " > It leads to a very messy classloading story. The classloader for the Tuscany > runtime classes/interfaces is NOT part of the web application's classloader > chain. Some classes in the runtime (including Tuscany and Axis2) uses Thread > context classloader as the starting point to resolve resources/classes and > it'll fail without the hacky classloader switching all over the place. > I did some experiement and found out the following should be the correct > packaging scheme: > 1) Only tuscany-tomcat-SNAPSHOT.jar should be copied to > $CATALINA_HOME/server/lib since it contains a class > "org.apache.tuscany.tomcat.TuscanyHost" extending > "org.apache.catalina.core.StandardHost" which is packaged in catalina.jar > under $CATALINA_HOME/server/lib. > 2) All the other Tuscany jars should be copied to $CATALINA_HOME/common/lib > With the new strategy,
[jira] Closed: (TUSCANY-262) The packaging scheme for Tuscany runtime and dependency jars is problematic against the Tomcat class loading hierarchy
[ http://issues.apache.org/jira/browse/TUSCANY-262?page=all ] Jeremy Boynes closed TUSCANY-262: - Resolution: Invalid Assign To: Jeremy Boynes Closing as invalid as we need to handle classloaders in an appropriate manner. > The packaging scheme for Tuscany runtime and dependency jars is problematic > against the Tomcat class loading hierarchy > -- > > Key: TUSCANY-262 > URL: http://issues.apache.org/jira/browse/TUSCANY-262 > Project: Tuscany > Type: Bug > Components: Java SCA Tomcat Integration > Reporter: Raymond Feng > Assignee: Jeremy Boynes > Priority: Critical > > As a result from the investigation on JIRA issue Tuscany-258, I found the > following problem. > Right now, most of the Tuscany and dependency jars are copied to > $CATALINA_HOME/server/lib. Is it by design? I think it's problematic and it's > the root cause of the problem > described by 258. > Here's a quote from the Tomcat 5.0 document @ > http://tomcat.apache.org/tomcat-5.0-doc/class-loader-howto.html: > "Catalina - This class loader is initialized to include all classes and > resources required to implement Tomcat 5 itself. These classes and resources > are TOTALLY invisible to web applications. All unpacked classes and resources > in $CATALINA_HOME/server/classes, as well as classes and resources in JAR > files under $CATALINA_HOME/server/lib, are made visible through this class > loader. " > It leads to a very messy classloading story. The classloader for the Tuscany > runtime classes/interfaces is NOT part of the web application's classloader > chain. Some classes in the runtime (including Tuscany and Axis2) uses Thread > context classloader as the starting point to resolve resources/classes and > it'll fail without the hacky classloader switching all over the place. > I did some experiement and found out the following should be the correct > packaging scheme: > 1) Only tuscany-tomcat-SNAPSHOT.jar should be copied to > $CATALINA_HOME/server/lib since it contains a class > "org.apache.tuscany.tomcat.TuscanyHost" extending > "org.apache.catalina.core.StandardHost" which is packaged in catalina.jar > under $CATALINA_HOME/server/lib. > 2) All the other Tuscany jars should be copied to $CATALINA_HOME/common/lib > With the new strategy, we can remove the classloader switching hacks in the > code base. > I can upload the patch if you guys agree with me. The patch includes the > changes against the build.xml (testing/tomcat), TuscanyContextListener.java > (sca/tomcat) and the rollbacks of the workaround committed by Ant under 258. > Thanks, > Raymond -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (TUSCANY-201) Allow extensions to WSDL processing
[ http://issues.apache.org/jira/browse/TUSCANY-201?page=all ] Jeremy Boynes closed TUSCANY-201: - Resolution: Fixed Patch applied - thanks. > Allow extensions to WSDL processing > --- > > Key: TUSCANY-201 > URL: http://issues.apache.org/jira/browse/TUSCANY-201 > Project: Tuscany > Type: Improvement > Components: Java SCA Core > Versions: M1 > Reporter: Jeremy Boynes > Assignee: Jeremy Boynes > Fix For: M1 > Attachments: wsdl_patch > > Allow extension code to customize the WSDL ExtensionRegistry to handle WSDL > extensions -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (TUSCANY-239) Need access to WSDLs by namespace
[ http://issues.apache.org/jira/browse/TUSCANY-239?page=all ] Jeremy Boynes closed TUSCANY-239: - Resolution: Fixed Patch applied - thanks > Need access to WSDLs by namespace > - > > Key: TUSCANY-239 > URL: http://issues.apache.org/jira/browse/TUSCANY-239 > Project: Tuscany > Type: Improvement > Components: Java SCA Core > Versions: M1 > Reporter: Daniel Kulp > Assignee: Jeremy Boynes > Fix For: M1 > Attachments: core.patch > > In order to replace usage of the SCDLAssemblyModelLoaderImpl with the > WSDLDefinitionRegistry, the registry needs to have a method to lookup the > definitions based on a namespace. > Patch is included. Patch for the Celtix binding will be forthcoming. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (TUSCANY-261) Tuscany-generated WAR should not package runtime jars under WEB-INF/lib
[ http://issues.apache.org/jira/browse/TUSCANY-261?page=all ] Jeremy Boynes resolved TUSCANY-261: --- Resolution: Fixed Patch applied - thanks I verified that the jars are not in the generated war, I have not verified that the sample still runs. Please close this issue (or let me know if you can't) if the changes works for you. > Tuscany-generated WAR should not package runtime jars under WEB-INF/lib > --- > > Key: TUSCANY-261 > URL: http://issues.apache.org/jira/browse/TUSCANY-261 > Project: Tuscany > Type: Bug > Components: Java BigBank Scenario > Versions: M1 > Reporter: Raymond Feng > Priority: Critical > Fix For: M1 > > Three jars (axiom-api, stax-api and wstx-asl) are packaged by the > account-SNAPSHOT.war under WEB-INF/lib. Since the by default the Tomcat web > application classloader uses parent-last classloading policy > (delegate=false), it creates different instances of classes/interfaces from > the jars in the application context and confuses the Tucany and Axis2 runtime > which in turn throws ClassCastException. > Here's the patch: > Index: C:/Tuscany/Apache/java/samples/bigbank/account/pom.xml > === > --- C:/Tuscany/Apache/java/samples/bigbank/account/pom.xml(revision > 399340) > +++ C:/Tuscany/Apache/java/samples/bigbank/account/pom.xml(working copy) > @@ -57,21 +57,21 @@ >stax >stax-api >1.0 > -compile > +provided > > > > woodstox > wstx-asl > 2.8.2 > -runtime > +provided > > > > ws-commons > axiom-api > 0.95 > -compile > +provided > > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TUSCANY-303) Single package override in tuscany-sca-plugin and tuscany-sdo-plugin insufficient
[ http://issues.apache.org/jira/browse/TUSCANY-303?page=all ] Jeremy Boynes updated TUSCANY-303: -- Component: Java SCA Tools Java SDO Tools > Single package override in tuscany-sca-plugin and tuscany-sdo-plugin > insufficient > -- > > Key: TUSCANY-303 > URL: http://issues.apache.org/jira/browse/TUSCANY-303 > Project: Tuscany > Type: New Feature > Components: Java SCA Tools, Java SDO Tools > Reporter: Rick Rineholt > > WSDL and schemas may reference many namespaces, a more general mapping scheme > that can override many target namespace to map to a java package is > ultimately required. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (TUSCANY-46) Scope for system components is not read from sidefile
[ http://issues.apache.org/jira/browse/TUSCANY-46?page=all ] Jeremy Boynes closed TUSCANY-46: Fix Version: M1 (was: Mx) Resolution: Won't Fix System Implementation does not support sidefiles. > Scope for system components is not read from sidefile > - > > Key: TUSCANY-46 > URL: http://issues.apache.org/jira/browse/TUSCANY-46 > Project: Tuscany > Type: Bug > Components: Specification > Versions: Mx > Reporter: Jeremy Boynes > Fix For: M1 > > I have a sidefile with a aervice declaration > > but in the logical model the scope is set to INSTANCE -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (TUSCANY-275) Define and implement Transport binding extension API
[ http://issues.apache.org/jira/browse/TUSCANY-275?page=all ] Jeremy Boynes closed TUSCANY-275: - Resolution: Duplicate > Define and implement Transport binding extension API > > > Key: TUSCANY-275 > URL: http://issues.apache.org/jira/browse/TUSCANY-275 > Project: Tuscany > Type: New Feature > Components: Java SCA Core > Versions: M1 > Reporter: Jean-Sebastien Delfino > Assignee: Jeremy Boynes > Fix For: M1 > > This was identified as a task for our first release (see > http://wiki.apache.org/ws/Tuscany/Tasks). > This will allow bindings to register with multiple transports (HTTP, JMS > etc). Used by the Axis2, Celtix and Jsonrpc bindings. > Jim and Jeremy volunteered to work on this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TUSCANY-177) Need a specification for autowire?
[ http://issues.apache.org/jira/browse/TUSCANY-177?page=all ] Jeremy Boynes updated TUSCANY-177: -- type: New Feature (was: Bug) > Need a specification for autowire? > -- > > Key: TUSCANY-177 > URL: http://issues.apache.org/jira/browse/TUSCANY-177 > Project: Tuscany > Type: New Feature > Components: Specification > Versions: Mx > Reporter: Jean-Sebastien Delfino > Assignee: Jeremy Boynes > Fix For: Mx > > Tuscany has introduced an Autowire capability. This needs to be contributed > back to the SCA spec collaboration assembly workgroup. See > http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200604.mbox/[EMAIL > PROTECTED] and the associated discussion thread for the details. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (TUSCANY-60) Need to externalize bootstrap process for the runtime
[ http://issues.apache.org/jira/browse/TUSCANY-60?page=all ] Jeremy Boynes closed TUSCANY-60: Resolution: Fixed > Need to externalize bootstrap process for the runtime > - > > Key: TUSCANY-60 > URL: http://issues.apache.org/jira/browse/TUSCANY-60 > Project: Tuscany > Type: Improvement > Components: Java SCA Core > Versions: M1 > Reporter: Jeremy Boynes > Assignee: Jeremy Boynes > Fix For: M1 > > Currently there is a bunch of duplicate code in various places that boots a > runtime. I know of: > * TuscanyRuntime > * TuscanyServletListener > * TuscantContextListener > These all bootstrap in very similar but slightly ways. We should externalize > the bootstrap process so that it can be shared by these implementations -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (TUSCANY-63) Need an SPI for co-ordination between EntryPoints and the infrastructure that will invoke them
[ http://issues.apache.org/jira/browse/TUSCANY-63?page=all ] Jeremy Boynes reassigned TUSCANY-63: Assign To: ant elder (was: Jeremy Boynes) Assigning to Ant as the Tomcat side is working > Need an SPI for co-ordination between EntryPoints and the infrastructure that > will invoke them > -- > > Key: TUSCANY-63 > URL: http://issues.apache.org/jira/browse/TUSCANY-63 > Project: Tuscany > Type: Bug > Components: Java SCA Core > Versions: M1 > Reporter: Jeremy Boynes > Assignee: ant elder > Priority: Blocker > Fix For: M1 > > In order to get the Tomcat integration code to create servlets for > web-services bound entry points it needed to know implementation details of > the binding. This will not allow integrators to freely embed Tuscany in > different environments or binding providers to contribute new bindings > without knowing something about those environments. > I would suggest that we define an SPI implemented by environment integrators > that will allow entry point implementations to request creation of transport > endpoints. So, taking the example of Axis2 and Tomcat, the Axis2 binding > would request a transport binding from the environment and which would be > activated when the EP started. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (TUSCANY-64) Tomcat integration code should be map to determine endpoint address
[ http://issues.apache.org/jira/browse/TUSCANY-64?page=all ] Jeremy Boynes closed TUSCANY-64: Resolution: Fixed Tomcat implementation of ServletHost will create a mapping for the supplied URI. > Tomcat integration code should be map to determine endpoint address > --- > > Key: TUSCANY-64 > URL: http://issues.apache.org/jira/browse/TUSCANY-64 > Project: Tuscany > Type: Bug > Components: Java SCA Axis Binding, Java SCA Tomcat Integration > Versions: Mx > Reporter: Jeremy Boynes > Fix For: Mx > > The current implementation hard codes the servlet path for the Axis2 servlet > to "/services/*" - this may not actually be what the user wants or where the > URI points to. Until we solve TUSCANY-63 then we should provide a way for the > integration code to determine the actual endpoint address from the EP. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (TUSCANY-395) Incorrect copyright statement
Incorrect copyright statement -- Key: TUSCANY-395 URL: http://issues.apache.org/jira/browse/TUSCANY-395 Project: Tuscany Type: Bug Components: Java SCA Samples Versions: Java-M1 Reporter: Jeremy Boynes Priority: Blocker Contains:
[jira] Assigned: (TUSCANY-527) First cut of the work scheduler implementation
[ http://issues.apache.org/jira/browse/TUSCANY-527?page=all ] Jeremy Boynes reassigned TUSCANY-527: - Assign To: Jeremy Boynes > First cut of the work scheduler implementation > -- > > Key: TUSCANY-527 > URL: http://issues.apache.org/jira/browse/TUSCANY-527 > Project: Tuscany > Type: New Feature > Components: Java SCA Core > Reporter: Meeraj Kunnumpurath > Assignee: Jeremy Boynes > Priority: Trivial > Attachments: workmanager.jar > > First-cut of the work scheduler implementation. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-527) First cut of the work scheduler implementation
[ http://issues.apache.org/jira/browse/TUSCANY-527?page=comments#action_12419907 ] Jeremy Boynes commented on TUSCANY-527: --- Looks good. Which version of the commonj API are you using and is there a version of it in the maven repo? > First cut of the work scheduler implementation > -- > > Key: TUSCANY-527 > URL: http://issues.apache.org/jira/browse/TUSCANY-527 > Project: Tuscany > Type: New Feature > Components: Java SCA Core > Reporter: Meeraj Kunnumpurath > Assignee: Jeremy Boynes > Priority: Trivial > Attachments: workmanager.jar > > First-cut of the work scheduler implementation. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-527) First cut of the work scheduler implementation
[ http://issues.apache.org/jira/browse/TUSCANY-527?page=comments#action_12420083 ] Jeremy Boynes commented on TUSCANY-527: --- Geronimo produce a version of the spec API but the latest released version has a couple of problems with it. They have been fixed and once they publish a SNAPSHOT I can update our build to use it. > First cut of the work scheduler implementation > -- > > Key: TUSCANY-527 > URL: http://issues.apache.org/jira/browse/TUSCANY-527 > Project: Tuscany > Type: New Feature > Components: Java SCA Core > Reporter: Meeraj Kunnumpurath > Assignee: Jeremy Boynes > Priority: Trivial > Attachments: jsr237.jar, workmanager.jar > > First-cut of the work scheduler implementation. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-537) Update version in POM
Update version in POM - Key: TUSCANY-537 URL: http://issues.apache.org/jira/browse/TUSCANY-537 Project: Tuscany Type: Improvement Components: Java SDO Implementation, Java SDO Tools, Java SDO Samples Reporter: Jeremy Boynes Assigned to: Jeremy Boynes The project POMs should be updated to reflect the future version (to avoid conflict with the M1 release). We should also update the EMF dependency to their final 2.2 release. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-538) Refactor Celtix binding
[ http://issues.apache.org/jira/browse/TUSCANY-538?page=comments#action_12420621 ] Jeremy Boynes commented on TUSCANY-538: --- I applied the patch but needed to tweak some files where the delta was applied twice. It built but please check I didn't mess up. Thanks > Refactor Celtix binding > --- > > Key: TUSCANY-538 > URL: http://issues.apache.org/jira/browse/TUSCANY-538 > Project: Tuscany > Type: Improvement > Components: Java SCA Celtix Binding > Versions: Java-M2 > Reporter: Jervis Liu > Priority: Minor > Attachments: jira538.patch > > We need to refactor the Celtix binding in sandbox to reflect changes in the > new recursive framework. Also more tests need to be added. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (TUSCANY-550) Supply chain sample for chianti
[ http://issues.apache.org/jira/browse/TUSCANY-550?page=all ] Jeremy Boynes reassigned TUSCANY-550: - Assignee: Jeremy Boynes (was: Ignacio Silva-Lepe) > Supply chain sample for chianti > --- > > Key: TUSCANY-550 > URL: http://issues.apache.org/jira/browse/TUSCANY-550 > Project: Tuscany > Issue Type: Test > Components: Java SCA Samples >Affects Versions: Java-Mx >Reporter: Ignacio Silva-Lepe > Assigned To: Jeremy Boynes > Fix For: Java-Mx > > Attachments: supplychain.zip > > > Upgrading supply chain sample to work with new version of spec under chianti -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-550) Supply chain sample for chianti
[ http://issues.apache.org/jira/browse/TUSCANY-550?page=all ] Jeremy Boynes closed TUSCANY-550. - Resolution: Fixed Patch applied - thank you Ignacio > Supply chain sample for chianti > --- > > Key: TUSCANY-550 > URL: http://issues.apache.org/jira/browse/TUSCANY-550 > Project: Tuscany > Issue Type: Test > Components: Java SCA Samples >Affects Versions: Java-Mx >Reporter: Ignacio Silva-Lepe > Assigned To: Jeremy Boynes > Fix For: Java-Mx > > Attachments: supplychain.zip > > > Upgrading supply chain sample to work with new version of spec under chianti -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-573) Race condition in ThreadPoolWorkManager
Race condition in ThreadPoolWorkManager --- Key: TUSCANY-573 URL: http://issues.apache.org/jira/browse/TUSCANY-573 Project: Tuscany Issue Type: Bug Reporter: Jeremy Boynes Problems running testSchedule testcase on single processor machines. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-573) Race condition in ThreadPoolWorkManager
[ http://issues.apache.org/jira/browse/TUSCANY-573?page=all ] Jeremy Boynes closed TUSCANY-573. - Resolution: Fixed Applied patch from Meeraj > Race condition in ThreadPoolWorkManager > --- > > Key: TUSCANY-573 > URL: http://issues.apache.org/jira/browse/TUSCANY-573 > Project: Tuscany > Issue Type: Bug >Reporter: Jeremy Boynes > > Problems running testSchedule testcase on single processor machines. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-574) URISyntaxException from launcher when jars reside in windows Maven repository
[ http://issues.apache.org/jira/browse/TUSCANY-574?page=all ]
Jeremy Boynes resolved TUSCANY-574.
---
Resolution: Fixed
Assignee: Jeremy Boynes
Fix applied.
I tested running a single sample on a Windows machine where the maven repo has
a space in it
I also tested running the launcher on OSX from an install directory with a
space in it
Please confirm this fix works for you
> URISyntaxException from launcher when jars reside in windows Maven repository
> -
>
> Key: TUSCANY-574
> URL: http://issues.apache.org/jira/browse/TUSCANY-574
> Project: Tuscany
> Issue Type: Bug
> Components: Java SCA Core
> Environment: Win XP, J2RE 1.5.0 IBM Windows 32 build
> pwi32dev-20060511 (SR2)
>Reporter: Matthew Sykes
> Assigned To: Jeremy Boynes
>Priority: Trivial
>
> When attempting to run maven from various samples directories:
> [INFO] [surefire:test]
> [INFO] Surefire report directory:
> C:\cygwin\home\sykesm\oss-code\tuscany\java\samples\sca\calculator\target\surefire-reports
> ---
> T E S T S
> ---
> Running calculator.CalculatorTestCase
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.38 sec <<<
> FAILURE!
> testCalculator(calculator.CalculatorTestCase) Time elapsed: 0.31 sec <<<
> ERROR!
> java.lang.IllegalArgumentException
> at java.net.URI.create(URI.java:854)
> at
> org.apache.tuscany.core.launcher.Launcher.getInstallDirectory(Launcher.java:177)
> at
> org.apache.tuscany.core.launcher.Launcher.bootRuntime(Launcher.java:104)
> at org.apache.tuscany.test.SCATestCase.setUp(SCATestCase.java:40)
> at calculator.CalculatorTestCase.setUp(CalculatorTestCase.java:32)
> at junit.framework.TestCase.runBare(TestCase.java:125)
> at junit.framework.TestResult$1.protect(TestResult.java:106)
> at junit.framework.TestResult.runProtected(TestResult.java:124)
> at junit.framework.TestResult.run(TestResult.java:109)
> at junit.framework.TestCase.run(TestCase.java:118)
> at junit.framework.TestSuite.runTest(TestSuite.java:208)
> at junit.framework.TestSuite.run(TestSuite.java:203)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:615)
> at
> org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:210)
> at
> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:135)
> at
> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:122)
> at org.apache.maven.surefire.Surefire.run(Surefire.java:129)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:615)
> at
> org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:225)
> at
> org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:747)
> Caused by: java.net.URISyntaxException: Illegal character in path at index
> 18: file:/C:/Documents and
> Settings/sykesm/.m2/repository/org/apache/tuscany/core/1.0-SNAPSHOT/core-1.0-SNAPSHOT.jar
> at java.net.URI$Parser.fail(URI.java:2821)
> at java.net.URI$Parser.checkChars(URI.java:2994)
> at java.net.URI$Parser.parseHierarchical(URI.java:3078)
> at java.net.URI$Parser.parse(URI.java:3026)
> at java.net.URI.(URI.java:590)
> at java.net.URI.create(URI.java:852)
> This appears to be due to how the Launcher teases out the directory
> containing the Tuscany code. Since the default location for the maven
> repository on windows has spaces in the directory names, the "URI" that was
> used was not valid. In order to get past this I made a very simple change:
> $ svn diff
> Index: sca/core/src/main/java/org/apache/tuscany/core/launcher/Launcher.java
> ===
> --- sca/core/src/main/java/org/apache/tuscany/core/launcher/Launcher.java
> (revision 425392)
> +++ sca/core/src/main/java/org/apache/tuscany/core/launcher/Launcher.java
> (working copy)
> @@ -168,13 +168,15 @@
> if (!"jar".equals(url.getProtocol())) {
> th
[jira] Assigned: (TUSCANY-609) Remove dependency on Geronimo work manager
[ http://issues.apache.org/jira/browse/TUSCANY-609?page=all ] Jeremy Boynes reassigned TUSCANY-609: - Assignee: Jeremy Boynes > Remove dependency on Geronimo work manager > -- > > Key: TUSCANY-609 > URL: http://issues.apache.org/jira/browse/TUSCANY-609 > Project: Tuscany > Issue Type: Improvement > Components: Java SCA Core >Affects Versions: Java-M2 > Environment: N/A >Reporter: Meeraj Kunnumpurath > Assigned To: Jeremy Boynes >Priority: Minor > Attachments: remove-geronimo-work-manager.txt > > > Remove dependency on Geronimo work manager. Following classes have been > removed, > 1. org.apache.tuscany.core.services.workmanager.DefaultWorkManager > 2. org.apache.tuscany.core.services.workmanager.DefaultWorkManagerTestCase > 3. org.apache.tuscany.core.services.workmanager.GeronimoWorkManagerTestCase > Following files have been amended > 1. > sca/core/src/main/java/org/apache/tuscany/core/policy/async/AsyncPolicyBuilder.java > 2. > sca/core/src/main/java/org/apache/tuscany/core/policy/async/AsyncInterceptor.java > 3. sca/core/pom.xml > 4. > sca/core/src/test/java/org/apache/tuscany/core/policy/async/AsyncInterceptorTestCase.java > Please find the patch attached > Ta > Meeraj -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-609) Remove dependency on Geronimo work manager
[ http://issues.apache.org/jira/browse/TUSCANY-609?page=all ] Jeremy Boynes closed TUSCANY-609. - Resolution: Fixed Patch applied thanks > Remove dependency on Geronimo work manager > -- > > Key: TUSCANY-609 > URL: http://issues.apache.org/jira/browse/TUSCANY-609 > Project: Tuscany > Issue Type: Improvement > Components: Java SCA Core >Affects Versions: Java-M2 > Environment: N/A >Reporter: Meeraj Kunnumpurath > Assigned To: Jeremy Boynes >Priority: Minor > Attachments: remove-geronimo-work-manager.txt > > > Remove dependency on Geronimo work manager. Following classes have been > removed, > 1. org.apache.tuscany.core.services.workmanager.DefaultWorkManager > 2. org.apache.tuscany.core.services.workmanager.DefaultWorkManagerTestCase > 3. org.apache.tuscany.core.services.workmanager.GeronimoWorkManagerTestCase > Following files have been amended > 1. > sca/core/src/main/java/org/apache/tuscany/core/policy/async/AsyncPolicyBuilder.java > 2. > sca/core/src/main/java/org/apache/tuscany/core/policy/async/AsyncInterceptor.java > 3. sca/core/pom.xml > 4. > sca/core/src/test/java/org/apache/tuscany/core/policy/async/AsyncInterceptorTestCase.java > Please find the patch attached > Ta > Meeraj -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-615) The SCDL syntax for reference doesn't conform to SCA spec 0.95
[ http://issues.apache.org/jira/browse/TUSCANY-615?page=comments#action_12427625 ] Jeremy Boynes commented on TUSCANY-615: --- There seem to be quite a few changes in this patch unrelated to the problem described above. Please can you submit these separately. > The SCDL syntax for reference doesn't conform to SCA spec 0.95 > -- > > Key: TUSCANY-615 > URL: http://issues.apache.org/jira/browse/TUSCANY-615 > Project: Tuscany > Issue Type: Bug > Components: Java SCA Core >Reporter: Raymond Feng > Assigned To: Raymond Feng >Priority: Critical > Attachments: rfeng-scdl.txt > > > With Rick check-in of r430621, I'm seeing the EchoBinding test case is > failing with the > following exception: > org.apache.tuscany.spi.loader.InvalidReferenceException: No target for > service [ClientService] > at org.apache.tuscany.core.loader.ServiceLoader.load(ServiceLoader.java) > at org.apache.tuscany.core.loader.ServiceLoader.load(ServiceLoader.java:1) > at > org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistryImpl.java:90) > at > org.apache.tuscany.core.implementation.composite.CompositeLoader.load(CompositeLoader.java:75) > at > org.apache.tuscany.core.implementation.composite.CompositeLoader.load(CompositeLoader.java:50) > at > org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistryImpl.java:90) > at > org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistryImpl.java:107) > at > org.apache.tuscany.core.implementation.composite.CompositeComponentTypeLoader.loadFromSidefile(CompositeComponentTypeLoader.java:46) > at > org.apache.tuscany.core.implementation.composite.CompositeComponentTypeLoader.load(CompositeComponentTypeLoader.java:38) > at > org.apache.tuscany.core.implementation.composite.CompositeComponentTypeLoader.load(CompositeComponentTypeLoader.java:20) > at > org.apache.tuscany.core.loader.LoaderRegistryImpl.loadComponentType(LoaderRegistryImpl.java:157) > at > org.apache.tuscany.core.deployer.DeployerImpl.load(DeployerImpl.java:111) > at > org.apache.tuscany.core.deployer.DeployerImpl.deploy(DeployerImpl.java:90) > at > org.apache.tuscany.core.launcher.Launcher.bootApplication(Launcher.java:171) > at org.apache.tuscany.test.SCATestCase.setUp(SCATestCase.java:63) > at echo.BootstrapTestCase.setUp(BootstrapTestCase.java:23) > at junit.framework.TestCase.runBare(TestCase.java:125) > at junit.framework.TestResult$1.protect(TestResult.java:106) > at junit.framework.TestResult.runProtected(TestResult.java:124) > at junit.framework.TestResult.run(TestResult.java:109) > at junit.framework.TestCase.run(TestCase.java:118) > at > org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:128) > at > org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196) > I adjusted the scdl file per SCA 0.95 spec: > http://www.osoa.org/xmlns/sca/1.0"; name="echo.sample"> > > > > Client > > > > EchoReference > > > > > > > Now the ServiceLoader.java is problematic because it assumes it'll get > "reference" before the "binding" which is not case per SCA 0.95 spec: > * > > * > wire-target-URI+ > > * > > * > property-value > > * > wire-target-URI > > > The ComponentLoader.java cannot handle the reference element either since > the SCA spec 0.95 also use the element content instead of "target" > attribute. > I attached a patch to fix the problem. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-616) JavaServiceContract introspection should use the ImplementationProcessor mechanism
JavaServiceContract introspection should use the ImplementationProcessor mechanism -- Key: TUSCANY-616 URL: http://issues.apache.org/jira/browse/TUSCANY-616 Project: Tuscany Issue Type: Improvement Components: Java SCA Core Reporter: Jeremy Boynes On the devlist, jboynes wrote: "Thinking a little more, using the ImplementationProcessor mechanisms seems like a better way to tackle this. One major advantage would be that we could add metadata to the service contract based on data type or annotations (e.g. adding metadata saying that a parameter should be bound using SDO which could be detected through the marker interface or an @SDO annotation)." -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-619) Fix classloader hierarchy for extensions
Fix classloader hierarchy for extensions Key: TUSCANY-619 URL: http://issues.apache.org/jira/browse/TUSCANY-619 Project: Tuscany Issue Type: Improvement Components: Java SCA Core Reporter: Jeremy Boynes Assigned To: Jeremy Boynes We have the start of a classloader hierarchy working for extension code but it is not being set up correctly in some environments e.g. the current web launcher. This is causing problems when loading extensions such as Axis. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-639) support for dependencies when referencing artifacts
[ http://issues.apache.org/jira/browse/TUSCANY-639?page=comments#action_12428586 ] Jeremy Boynes commented on TUSCANY-639: --- Another place where this applies is on eg: > support for dependencies when referencing artifacts > --- > > Key: TUSCANY-639 > URL: http://issues.apache.org/jira/browse/TUSCANY-639 > Project: Tuscany > Issue Type: New Feature > Components: Java SCA Core >Reporter: Jervis Liu > > support for dependencies when referencing artifacts, for example, . > . In this > case, we can probably use some maven APIs to access the repo to resolve > dependencies. See ArtifactRepository and it's implementation as a starting > point. > Enclosed below is IRC chat related to this topic. > (01:55:14) jervisliu: I dont quite understand what you mean by "I think this > can be handled by the mechanism and the use of the applicable > location attributes e.g. wsdlLocation" > (01:55:35) jervisliu: what kind of mechanism are you refering to? > (01:56:08) jboynes: the ability to add elements into SCDL to > extend the classpath for the composite > (01:56:55) jervisliu: this is not part of spec, right? > (01:57:07) jboynes: no, it's a tuscany feature > (01:57:33) jboynes: given the spec doesn't talk about packaging yet :-( > (01:58:19) jervisliu: see. but it looks like there is an easier way to > achieve same result. for example, the celtix-binding.jar can have a > default.scdl > (01:58:31) jboynes: sure > (01:58:34) jboynes: you can do both > (01:58:37) jervisliu: and the dependency of celtix-binding.jar can be > specified in MANIFEST > (01:58:48) jboynes: ah, no not really > (01:59:09) jboynes: people hate manifest Class-Paths > (01:59:19) jboynes: they still work and can be used > (01:59:24) jervisliu: this can be done very easily in maven, and is a well > understood way to resolve classpath dependencies > (01:59:31) jboynes: yes > (01:59:53) jboynes: is quite maven friendly ;-) > (02:00:36) jboynes: I also mentioned having the implementation use maven > metadata if present in the jar > (02:00:48) jervisliu: sure. I remember there was talk about a maven like > dependency element. > (02:00:58) jboynes: yep - - I just went and did it > (02:01:19) jboynes: see ArtifactRepository and it's implementation > (02:01:54) jboynes: having an implementation that used maven itself to locate > the artifacts would be real cool > (02:01:54) jervisliu: oh, i dont know its done already. ;-) > (02:03:57) jervisliu: cool. so the scdl file under ext dir (using > ) can only used for one binding implementation. right? > (02:04:32) jboynes: well, it's a composite so it could contain components > implemented by other nested composites > (02:05:35) jervisliu: but then all dependencies will be merged to compose a > classpath, > (02:05:50) jboynes: no, the composite classloader is hierarchical > (02:06:20) jboynes: the nested composites would be in child classloades > (02:06:40) jervisliu: oklets have a concrete example. > (02:07:08) jervisliu: how to write this scdl if we have both axis and celtix > libraries under ext? > (02:07:27) jboynes: well, you could just put them both in the ext directory > (02:07:43) jboynes: then you wouldn't need any scdl > (02:07:54) jboynes: s/libraries/bindings > (02:08:41) jboynes: i.e put binding-axis.jar and binding-celtix.jar in ext > (02:08:56) jervisliu: then when using , which one is actually > being used? > (02:09:07) jboynes: why does it matter? > (02:09:24) jervisliu: well, i just sent out an email to discuss this. > (02:09:24) jboynes: it could be either but they both impl the spec > (02:09:43) jboynes: by saying the user us saying they don't care > (02:10:01) jervisliu: maybe it does not matter. but users still wants to know > whichi implementation they are actually using > (02:10:41) jboynes: why? > (02:10:56) jervisliu: and in the real world, it still matters. for example, > both axis2 and celtix have their own configuration files, the default config > file shipped with binding probably works for 99% situations > (02:11:12) jervisliu: but it might be the case that they need to modify the > config file. > (02:11:29) jboynes: so in the "real" world how many users will actually use > both concurrently? > (02:11:32) jervisliu: in this case, they do need to know which implementation > is loaded by tuscany > (02:11:35) jboynes: no > (02:11:48) jboynes: they need to make sure that they use the implementation > they modified > (02:12:05) jboynes: so if they modified celtix they should use > binding.celtix.ws > (02:12:21) jboynes: as that application will not work on a runtime that only > has axis > (02:12:59) jervisliu: ok. i think i m convinced on this. > (02:14:06) jervisliu: the reason why i came out with this question is that i > had thought we ship Tuscany kit with a default ext d
[jira] Created: (TUSCANY-640) Service and Reference do not support multiple elements
Service and Reference do not support multiple elements Key: TUSCANY-640 URL: http://issues.apache.org/jira/browse/TUSCANY-640 Project: Tuscany Issue Type: Bug Components: Java SCA Core Reporter: Jeremy Boynes Priority: Critical According to the spec, Service and Reference definitions can have multiple bindings associated with them. Our config model and the associated loaders and builders only support a single binding -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-673) support scdlLocation attribute on
support scdlLocation attribute on Key: TUSCANY-673 URL: http://issues.apache.org/jira/browse/TUSCANY-673 Project: Tuscany Issue Type: Improvement Components: Java SCA Core Reporter: Jeremy Boynes Assigned To: Ignacio Silva-Lepe When using a composite as an implementation, we should provide a way for the user to specify the location of the SCDL for the composite ... The location should be resolved relative to the location of the outer composite. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-673) support scdlLocation attribute on
[ http://issues.apache.org/jira/browse/TUSCANY-673?page=all ] Jeremy Boynes closed TUSCANY-673. - Resolution: Fixed Patch applied - thanks > support scdlLocation attribute on > > > Key: TUSCANY-673 > URL: http://issues.apache.org/jira/browse/TUSCANY-673 > Project: Tuscany > Issue Type: Improvement > Components: Java SCA Core >Reporter: Jeremy Boynes > Assigned To: Ignacio Silva-Lepe > Attachments: ImplementationCompositeLoader.patch, > ImplementationCompositeLoaderAndTest.patch > > > When using a composite as an implementation, we should provide a way for the > user to specify the location of the SCDL for the composite > > > ... > The location should be resolved relative to the location of the outer > composite. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-679) InterfaceWSDLLoader mismatch btw. @Constructor annot. and actual Constructor parms
[ http://issues.apache.org/jira/browse/TUSCANY-679?page=all ]
Jeremy Boynes closed TUSCANY-679.
-
Resolution: Fixed
Patch applied fine - thanks
> InterfaceWSDLLoader mismatch btw. @Constructor annot. and actual Constructor
> parms
> ---
>
> Key: TUSCANY-679
> URL: http://issues.apache.org/jira/browse/TUSCANY-679
> Project: Tuscany
> Issue Type: Bug
> Components: Java SCA Axis Binding
>Affects Versions: Java-M2
>Reporter: Scott Kurz
> Attachments: InterfaceWSDLLoader.ConstructorFix.patch
>
>
> PROBLEM:
> Mismatch btw. annotation:
> @Constructor({"registry"})
> and Constructor:
> public InterfaceWSDLLoader(@Autowire LoaderRegistry registry,
>@Autowire WSDLDefinitionRegistry wsdlRegistry)
> {
>
> SYMPTOM:
> org.apache.tuscany.core.implementation.processor.InvalidAutowireException:
> Names in @Constructor and autowire parameter do not match at 2 [public
> org.apache.tuscany.idl.wsdl.InterfaceWSDLLoader(org.apache.tuscany.spi.loader.LoaderRegistry,org.apache.tuscany.idl.wsdl.WSDLDefinitionRegistry)]
> Context stack trace: [tuscany.system][intf.wsdl.loader]
> at
> org.apache.tuscany.core.implementation.processor.ImplementationProcessorServiceImpl.processAutowire(ImplementationProcessorServiceImpl.java:186)
> at
> org.apache.tuscany.core.implementation.processor.ImplementationProcessorServiceImpl.processParam(ImplementationProcessorServiceImpl.java:113)
> at
> org.apache.tuscany.core.implementation.processor.ConstructorProcessor.visitConstructor(ConstructorProcessor.java:94)
> at
> org.apache.tuscany.core.implementation.IntrospectionRegistryImpl.introspect(IntrospectionRegistryImpl.java:83)
> at
> org.apache.tuscany.core.implementation.system.loader.SystemComponentTypeLoader.loadByIntrospection(SystemComponentTypeLoader.java:85)
> at
> org.apache.tuscany.core.implementation.system.loader.SystemComponentTypeLoader.load(SystemComponentTypeLoader.java:69)
> at
> org.apache.tuscany.core.implementation.system.loader.SystemComponentTypeLoader.load(SystemComponentTypeLoader.java:42)
> at
> org.apache.tuscany.core.loader.LoaderRegistryImpl.loadComponentType(LoaderRegistryImpl.java:159)
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (TUSCANY-688) WAR Maven Plugin for Tuscany
[ http://issues.apache.org/jira/browse/TUSCANY-688?page=all ] Jeremy Boynes reassigned TUSCANY-688: - Assignee: Jeremy Boynes > WAR Maven Plugin for Tuscany > > > Key: TUSCANY-688 > URL: http://issues.apache.org/jira/browse/TUSCANY-688 > Project: Tuscany > Issue Type: New Feature > Components: Java SCA Tools >Affects Versions: Java-M2 >Reporter: Meeraj Kunnumpurath > Assigned To: Jeremy Boynes >Priority: Minor > Attachments: tuscany-war-plugin-src.jar > > > Hi, > This is the first cut for the Maven plugin for the Tuscany war plugin. The > plugin is attached to the packaged phase and works on the WAR file produced > by the Maven WAR plugin. It accepts the boot and extension libraries as > configuration parameteres and adds them to the original WAR at relavant > locations. Outstanding stuff, > Verify the presence of the required context listeners in web XML and add > them if not present. > Defaults handling, don't know what the defaults are :-) > Here is a usage pattern, > > > 4.0.0 > MyWar > war > MyCompany > My War > 1.0 > > > > org.apache.tuscany > tuscany-war-plugin > true > > > tuscany-war > > tuscany-war > > > > > > > commons-io > commons-io > 1.2 > > > > > commons-collections > commons-collections > 3.2 > > > > > > > > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-688) WAR Maven Plugin for Tuscany
[ http://issues.apache.org/jira/browse/TUSCANY-688?page=comments#action_12432526 ] Jeremy Boynes commented on TUSCANY-688: --- Patch applied - thanks > WAR Maven Plugin for Tuscany > > > Key: TUSCANY-688 > URL: http://issues.apache.org/jira/browse/TUSCANY-688 > Project: Tuscany > Issue Type: New Feature > Components: Java SCA Tools >Affects Versions: Java-M2 >Reporter: Meeraj Kunnumpurath > Assigned To: Jeremy Boynes >Priority: Minor > Attachments: tuscany-war-plugin-src.jar > > > Hi, > This is the first cut for the Maven plugin for the Tuscany war plugin. The > plugin is attached to the packaged phase and works on the WAR file produced > by the Maven WAR plugin. It accepts the boot and extension libraries as > configuration parameteres and adds them to the original WAR at relavant > locations. Outstanding stuff, > Verify the presence of the required context listeners in web XML and add > them if not present. > Defaults handling, don't know what the defaults are :-) > Here is a usage pattern, > > > 4.0.0 > MyWar > war > MyCompany > My War > 1.0 > > > > org.apache.tuscany > tuscany-war-plugin > true > > > tuscany-war > > tuscany-war > > > > > > > commons-io > commons-io > 1.2 > > > > > commons-collections > commons-collections > 3.2 > > > > > > > > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-699) Allow bootstrap of tuscanny from spring web apps / struts apps etc
[ http://issues.apache.org/jira/browse/TUSCANY-699?page=comments#action_12432929 ] Jeremy Boynes commented on TUSCANY-699: --- I would (strongly) prefer we do not introduce a dependency on clogging. > Allow bootstrap of tuscanny from spring web apps / struts apps etc > -- > > Key: TUSCANY-699 > URL: http://issues.apache.org/jira/browse/TUSCANY-699 > Project: Tuscany > Issue Type: Improvement > Components: Java SCA Core >Affects Versions: Java-M2 >Reporter: Andy Piper > Attachments: springlaunch.patch > > > Spring provides a wealth of web app integration components. To reimplement > these in Tuscany would be prohibitive, instead we need to allow Spring to > bootstrap Tuscany and use its standard extension mechanisms. > I have a patch. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (TUSCANY-699) Allow bootstrap of tuscanny from spring web apps / struts apps etc
[ http://issues.apache.org/jira/browse/TUSCANY-699?page=all ] Jeremy Boynes reassigned TUSCANY-699: - Assignee: Jeremy Boynes > Allow bootstrap of tuscanny from spring web apps / struts apps etc > -- > > Key: TUSCANY-699 > URL: http://issues.apache.org/jira/browse/TUSCANY-699 > Project: Tuscany > Issue Type: Improvement > Components: Java SCA Core >Affects Versions: Java-M2 >Reporter: Andy Piper > Assigned To: Jeremy Boynes > Attachments: springlaunch.patch > > > Spring provides a wealth of web app integration components. To reimplement > these in Tuscany would be prohibitive, instead we need to allow Spring to > bootstrap Tuscany and use its standard extension mechanisms. > I have a patch. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-688) WAR Maven Plugin for Tuscany
[ http://issues.apache.org/jira/browse/TUSCANY-688?page=comments#action_12433190 ] Jeremy Boynes commented on TUSCANY-688: --- Patches applied - thanks. I did have a slight problem with the sample before applying the sample patch in that the archiver objected to a duplicate entry. It would perhaps be helpful if the plugin could detect duplicates and only add them once. This may prevent duplicates as well - e.g. api ends up in both WEB-INF/lib and in WEB-INF/tuscany/boot > WAR Maven Plugin for Tuscany > > > Key: TUSCANY-688 > URL: http://issues.apache.org/jira/browse/TUSCANY-688 > Project: Tuscany > Issue Type: New Feature > Components: Java SCA Tools >Affects Versions: Java-M2 >Reporter: Meeraj Kunnumpurath > Assigned To: Jeremy Boynes >Priority: Minor > Attachments: tuscany-war-patch-20060906.txt, > tuscany-war-plugin-patch-20060906-2.txt, tuscany-war-plugin-src.jar, > tuscany-webapp-sample-patch-20060906.txt > > > Hi, > This is the first cut for the Maven plugin for the Tuscany war plugin. The > plugin is attached to the packaged phase and works on the WAR file produced > by the Maven WAR plugin. It accepts the boot and extension libraries as > configuration parameteres and adds them to the original WAR at relavant > locations. Outstanding stuff, > Verify the presence of the required context listeners in web XML and add > them if not present. > Defaults handling, don't know what the defaults are :-) > Here is a usage pattern, > > > 4.0.0 > MyWar > war > MyCompany > My War > 1.0 > > > > org.apache.tuscany > tuscany-war-plugin > true > > > tuscany-war > > tuscany-war > > > > > > > commons-io > commons-io > 1.2 > > > > > commons-collections > commons-collections > 3.2 > > > > > > > > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-688) WAR Maven Plugin for Tuscany
[ http://issues.apache.org/jira/browse/TUSCANY-688?page=comments#action_12433202 ] Jeremy Boynes commented on TUSCANY-688: --- The duplicate problem seems to occur if I run the build twice: $ mvn -o clean $ mvn -o package # OK $ mvn -o package # Fails > WAR Maven Plugin for Tuscany > > > Key: TUSCANY-688 > URL: http://issues.apache.org/jira/browse/TUSCANY-688 > Project: Tuscany > Issue Type: New Feature > Components: Java SCA Tools >Affects Versions: Java-M2 >Reporter: Meeraj Kunnumpurath > Assigned To: Jeremy Boynes >Priority: Minor > Attachments: tuscany-war-patch-20060906.txt, > tuscany-war-plugin-patch-20060906-2.txt, tuscany-war-plugin-src.jar, > tuscany-webapp-sample-patch-20060906.txt > > > Hi, > This is the first cut for the Maven plugin for the Tuscany war plugin. The > plugin is attached to the packaged phase and works on the WAR file produced > by the Maven WAR plugin. It accepts the boot and extension libraries as > configuration parameteres and adds them to the original WAR at relavant > locations. Outstanding stuff, > Verify the presence of the required context listeners in web XML and add > them if not present. > Defaults handling, don't know what the defaults are :-) > Here is a usage pattern, > > > 4.0.0 > MyWar > war > MyCompany > My War > 1.0 > > > > org.apache.tuscany > tuscany-war-plugin > true > > > tuscany-war > > tuscany-war > > > > > > > commons-io > commons-io > 1.2 > > > > > commons-collections > commons-collections > 3.2 > > > > > > > > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-715) Update tools module to use latest XmlSchema version
Update tools module to use latest XmlSchema version --- Key: TUSCANY-715 URL: http://issues.apache.org/jira/browse/TUSCANY-715 Project: Tuscany Issue Type: Bug Components: Java SCA Tools Reporter: Jeremy Boynes Priority: Critical The API for XmlSchema has changed since the 1.0.2 version. We are using a newer version due to updates in Axis2 and the tools need to be modified to use its new API. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1) port build process to Maven2
[ http://issues.apache.org/jira/browse/TUSCANY-1?page=all ] Jeremy Boynes updated TUSCANY-1: Component: Build System Change component to "Build System" > port build process to Maven2 > > > Key: TUSCANY-1 > URL: http://issues.apache.org/jira/browse/TUSCANY-1 > Project: Tuscany > Type: Improvement > Components: Build System > Environment: Java > Reporter: Jack D. Unrue > > Port the existing Tuscany/Java build process from Maven1.x to Maven2.x. Leave > the existing maven files in place until the new build is working and there is > consensus to remove the old build. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (TUSCANY-4) Webite should clearly indicate that the project is under incubation
Webite should clearly indicate that the project is under incubation --- Key: TUSCANY-4 URL: http://issues.apache.org/jira/browse/TUSCANY-4 Project: Tuscany Type: Bug Components: Website Reporter: Jeremy Boynes The website should clearly indicate that the project is still under incubation -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (TUSCANY-1) port build process to Maven2
[ http://issues.apache.org/jira/browse/TUSCANY-1?page=all ] Jeremy Boynes reassigned TUSCANY-1: --- Assign To: Jeremy Boynes > port build process to Maven2 > > > Key: TUSCANY-1 > URL: http://issues.apache.org/jira/browse/TUSCANY-1 > Project: Tuscany > Type: Improvement > Components: Build System > Environment: Java > Reporter: Jack D. Unrue > Assignee: Jeremy Boynes > Attachments: tuscany_m2_poms.zip > > Port the existing Tuscany/Java build process from Maven1.x to Maven2.x. Leave > the existing maven files in place until the new build is working and there is > consensus to remove the old build. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (TUSCANY-5) DAS build leaves files in current directory
DAS build leaves files in current directory --- Key: TUSCANY-5 URL: http://issues.apache.org/jira/browse/TUSCANY-5 Project: Tuscany Type: Bug Reporter: Jeremy Boynes derby.log and dastest files get left in the current directory These should be under target so they don't contaminate SVN and so they will be removed with a mvn clean -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (TUSCANY-6) Method names in ResourceLoader are inconsistent with ClassLoader
Method names in ResourceLoader are inconsistent with ClassLoader Key: TUSCANY-6 URL: http://issues.apache.org/jira/browse/TUSCANY-6 Project: Tuscany Type: Improvement Components: Java SCA Common Reporter: Jeremy Boynes The getResouces(String) method behaves differently to the similar method on ClassLoader in that it only searches the current resource loader but not its parents. I would suggest renaming: getAllResources(String) to getResources(String) and getResources(String) to getDeclaredResources(String) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (TUSCANY-7) Several exceptions are thrown the first time the DAS tests are run
Several exceptions are thrown the first time the DAS tests are run -- Key: TUSCANY-7 URL: http://issues.apache.org/jira/browse/TUSCANY-7 Project: Tuscany Type: Bug Components: Java DAS RDB Reporter: Jeremy Boynes Assigned to: Kevin Williams On the first run (or any time the dastest database is deleted), the test logs several stacktraces about tables not being present. The tests then go on to complete. This is confusing for users who typically would not expect this behaviour. The tables should be dropped silently or less distressing messages should be logged. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
