On Feb 13, 2007, at 2:25 PM, Jim Marino wrote:
Log:
make the test domain name configurable
Hi,
I was just curious how you see the test domain configuration being
used. Sounds like it is the right thing to do since other runtimes
will need to allow it but I was wondering if there is someth
It's not a dependency on Java6, it's a dependency on StAX
(java.xml.stream). That happens to be included in Java6, but it is
also included in Java5 Enterprise Edition and is available separately
for use on Java5 Standard Edition and J2SE 1.4.
It seems the SDO implementation now has a hard r
On Feb 12, 2007, at 6:11 PM, Jim Marino wrote:
Agreed, however, it is not apparent from that test what is really
going on or what the intent is.
The propertyTest itest? Agreed.
I'm adding a bunch of stuff to that :-)
--
Jeremy
-
On Feb 12, 2007, at 6:02 PM, Jim Marino wrote:
Why are we testing complex property deserialization in an
integration test? I would think these should be unit tests and run
as part of the checkin build?
I think we need both.
Unit tests to check the basic conversions and which should also ca
Trying to run the propertyTest I get:
Caused by:
org.apache.tuscany.core.databinding.javabeans.XML2JavaMapperException: o
rg.apache.tuscany.core.databinding.javabeans.XML2JavaMapperException:
No field or setter method to configure xml data
at
org.apache.tuscany.core.databinding.jav
On Feb 12, 2007, at 5:29 PM, Jim Marino wrote:
On Feb 12, 2007, at 5:17 PM, Rick Rineholt wrote:
You list the dependencies here in the parent pom then in child
poms you don't list the version's and they use the parents. One
means of controlling the version you're using across multiple sub
On Feb 12, 2007, at 12:18 PM, Raymond Feng wrote:
Hi,
In the latest calculator sample, it demonstrates the usage of itest
where we define a harness composite as follows:
http://www.osoa.org/xmlns/sca/1.0";
xmlns:tuscany="http://tuscany.apache.org/xmlns/sca/1.0";
name="CalculatorTestHarnessC
On Feb 12, 2007, at 7:57 AM, ant elder wrote:
FYI, our board report is due in two days. I've started adding some
text to
the empty template to get things going, feel free to edit/amend/
rewrite as
you see fit: http://wiki.apache.org/incubator/February2007
Thanks Ant. I added a couple of th
I started to look at migrating the itests to 1.0 and found myself
struggling to understand just what they do. For example:
https://svn.apache.org/repos/asf/incubator/tuscany/java/testing/sca/
itest/specTest/src/test/java/org/apache/tuscany/sca/test/spec/
ComponentServiceReferenceTest.java
is
On Feb 12, 2007, at 9:46 AM, Jim Marino wrote:
On Feb 12, 2007, at 8:01 AM, haleh mahbod wrote:
Does bring up of runtime include a successful run of iTest?
I was specifically referring to the standalone runtime but it
appears Jeremy also has the itest plugin working with the really
neat ab
On Feb 12, 2007, at 2:48 AM, Simon Laws wrote:
Thanks Jeremy for commenting. I am of course now looking back
through the
archive and seeing that discussions are underway. Doh, sorry about
that.
From the distributed assembly [1], federated deployment [2], physical
component definition [3]
On Feb 12, 2007, at 4:48 AM, Valerio Schiavoni wrote:
On 2/9/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote:
Fractal would be great :-)
Yes!
The tag for M2 is here:
http://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sca/1.0-
incubator-M2/
i get this error when trying 'mv
, but didn't work. There is no option to
assign the
task to me.
Adriano Crestani
On 2/11/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote:
That was the account I added (and the email associated with it is the
one you sent this from). You might try logging out/in.
What is not working for yo
That was the account I added (and the email associated with it is the
one you sent this from). You might try logging out/in.
What is not working for you?
--
Jeremy
On Feb 11, 2007, at 4:23 PM, Adriano Crestani wrote:
Sorry Jeremy, but I'm not being able to access the developer
options. Have
On Feb 10, 2007, at 9:06 AM, Luciano Resende wrote:
Hi Jeremy
I'm working on a implementation based on a slightly updated model
that
Raymond had proposed and already committed to trunk. I should have
something
in the next couple days available.
OK, thanks.
For the itest plugin, I woul
On Feb 6, 2007, at 12:11 PM, Jeremy Boynes wrote:
One of the things that is changing in the spec is the way in which
user code outside SCA can access SCA resources. The
CompositeContext and CurrentCompositeContext classes have been
replaced with ComponentContext. You can see a prototype of
On Feb 9, 2007, at 5:48 PM, Raymond Feng wrote:
Hi,
I have changed the branch to use "0.1-integration-incubating-
SNAPSHOT" as the version id.
Thanks
--
Jeremy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional com
On Feb 9, 2007, at 4:56 PM, haleh mahbod wrote:
"Extension developer would generally not work off the latest code (I
generally discourage people from doing this as the state of trunk may
be in flux). They would tend to go off a published release."
OK. Although it seems like all discussions are
With the change to using a ComponentManager and URIs for components
internally, I think we need to decouple ClassLoaders from
CompositeComponent as well.
I'm going to add a separate ClassLoaderRegistry to the runtime domain
to do this, something like:
interface ClassLoaderRegistry {
voi
On Feb 9, 2007, at 9:10 AM, Jeremy Boynes wrote:
I'll add a module in the sandbox for fractal.
https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/fractal
Have at it :-)
--
Jeremy
-
To unsubscribe, e-mail: [
to Eclipse, try "mvn -Peclipse eclipse:eclipse" but YMMV
I'll add a module in the sandbox for fractal.
--
Jeremy
On Feb 9, 2007, at 8:27 AM, Valerio Schiavoni wrote:
Hello Jeremy,
thanks for your quick answer.
On 2/9/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote:
What language are
To prevent confusion with trunk, please change the artifactIds for
this branch (I'd suggest using a different groupId or version).
Thanks
--
Jeremy
On Feb 8, 2007, at 7:05 PM, Jean-Sebastien Delfino wrote:
[snip]
People have talked about working on scenarios and Jira issues, but
it's not c
On Feb 9, 2007, at 5:59 AM, Simon Laws wrote:
Thanks Jim for pointing me in the right direction. I'll go and
catch up on
the deployment work you've highlighted. I don't know if this is
currently in
scope but I would like to have as a target the ability to wire
components
from different (lang
Welcome to the project!
You don't even need to do all the extensions. Adding a container is
like adding a Maven plugin - a self contained module that uses
interfaces from the kernel. You can ignore all the other extensions
and focus on yours.
What language are you looking to support? If i
On Feb 8, 2007, at 4:42 PM, Jeremy Boynes wrote:
On Feb 8, 2007, at 3:26 PM, Meeraj Kunnumpurath wrote:
Also, for the JavaAtomicComponent, I am planning to pass in the
instance factory into the component from the builder, so that it
can be used later when createInstance is called. I am also
I think there are a couple of extra things needed here:
Firstly, just a list of 's is not going to be enough. We
really need each one to be configurable, something like:
where the element identifies the appropriate clone
interceptor.
We also need to be able to define
On Feb 8, 2007, at 11:41 AM, Sam Ruby wrote:
On 2/8/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote:
>
> So I think we need a branch to do this stabilization work
I'm disturbed by this proposal as I don't think we have consensus in
the community yet on this issue.
Thi
On 2/7/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
Like Venkat I'm also looking for a more stable runtime environment.
I want that stable environment to bring-up end to end scenarios,
including Bigbank, variations of BigBank and Calculator similar to what
we've been running with the C+
[
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
[
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
On 2/7/07, Rick Rineholt <[EMAIL PROTECTED]> wrote:
Also, the plan was just to have it temporary an it was my understanding
there was planned work to split Axis binding between Services and
Reference which would have made that unnecessary. I don't think however
that was ever checked in.
OK for
On 2/7/07, Rick Rineholt <[EMAIL PROTECTED]> wrote:
Jeremy Boynes wrote:
> On 1/11/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>> Author: rineholt
>> Date: Thu Jan 11 10:31:12 2007
>> New Revision: 495320
>>
>> URL: http://svn.apache.org/viewvc?v
On 1/11/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Author: rineholt
Date: Thu Jan 11 10:31:12 2007
New Revision: 495320
URL: http://svn.apache.org/viewvc?view=rev&rev=495320
Log:
Give standalone launcher access to servlet-api need by axis
binding.axis2/mvn.out
We should not be adding de
On Feb 7, 2007, at 10:48 AM, Venkata Krishnan wrote:
Hi,
Heres my opinion from the perspective of some items that I have
owned up to
do quite a while back - support for complex properties and multivalued
properties. I'd see them as some fundamental things that a user might
expect to see out
Done.
--
Jeremy
On Feb 7, 2007, at 10:34 AM, Luciano Resende wrote:
Adriano Crestani has been helping DAS for couple months now, he had
contributed on a DAS tutorial initiative, and recently he has been
discussing and contributing on a C++ implementation of a DAS. I'd
like to
give him de
Yes, the "installable distribution" is the jar/tgz that is generated
by the assembly module.
It's not quite the same as M2 because, in line with the modularity
story, it does not have dependencies on extension modules. Those
would be installed separately (either manually by the user or as par
Patches for new functionality such as this should be submitted
against trunk.
--
Jeremy
On Feb 7, 2007, at 5:16 AM, Simon Nash wrote:
A March release with basic functional improvements in a consumable
package
(kernel, selected extensions, and tools) makes sense to me.
As well as the items
On Feb 7, 2007, at 5:49 AM, Dan Murphy wrote:
It would make good sense to...
I've just started some migration of tuscany tests to the SDO CTS -
would you envisage the SDO CTS having a seperate release or combining
the two ?
I would think CTS would be a separate release. It's goal is to define
How does this relate to the existing CompositeClassLoader?
--
Jeremy
On Feb 6, 2007, at 4:48 PM, [EMAIL PROTECTED] wrote:
Author: rfeng
Date: Tue Feb 6 16:48:21 2007
New Revision: 504392
URL: http://svn.apache.org/viewvc?view=rev&rev=504392
Log:
Copy the MultiParentClassLoader from Axis2
Add
As part of the recent flurry of release plans, there's been no
discussion of an SDO release. Is that something we should do?
--
Jeremy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECT
Sebastien mentioned stabilizing "tools like WSDL2Java and Java2WSDL
etc." recently and Kelvin and I were previously discussing moving
those tools out of SCA and into SDO on the basis that they actually
don't have any dependency on SCA but do on SDO and EMF. Ant has now
moved them to the axi
Guys,
I'm a little confused here - so far we seem to have 3 different
people volunteering to manage 3 different releases. We now have a
very very long list of "requirements" many of which have not been
discussed on the list and most of which do not have names against
them or really relate
What is DeploymentContext used for?
--
Jeremy
On Feb 6, 2007, at 3:32 PM, [EMAIL PROTECTED] wrote:
Author: rfeng
Date: Tue Feb 6 15:32:03 2007
New Revision: 504366
URL: http://svn.apache.org/viewvc?view=rev&rev=504366
Log:
Add the ArtifactResolver SPI
Added:
incubator/tuscany/java/sca/ke
One of the things that is changing in the spec is the way in which
user code outside SCA can access SCA resources. The CompositeContext
and CurrentCompositeContext classes have been replaced with
ComponentContext. You can see a prototype of this in the spec/sca-api-
r1.0 module.
This has a
What IRC?
--
Jeremy
On Feb 6, 2007, at 8:06 AM, Rick Rineholt wrote:
This isn't answering your question; but I'd like to see a version
of the iTest
framework running against the trunk as discussed in the last IRC.
This would
allow bring up whole user scenarios and provide a means to quickl
On Feb 3, 2007, at 1:01 PM, Meeraj Kunnumpurath wrote:
6. What I would suggest is to start a new builder framework in
parallel and deprecate the old one. The current deployer can
continue to use the old builder framework and the federted one will
use the new one. Once we have the builders fo
On Jan 29, 2007, at 6:50 PM, Jeremy Boynes wrote:
Instead, I think the data sent should define the configuration data
needed by the JavaComponentBuilder, something like:
http://tuscany.apache.org/xmlns/java/
1.0"
uri="http://www.example.com/D1/
On Feb 3, 2007, at 8:39 AM, [EMAIL PROTECTED] wrote:
Author: meerajk
Date: Sat Feb 3 08:39:15 2007
New Revision: 503232
URL: http://svn.apache.org/viewvc?view=rev&rev=503232
Log:
Physical component model.
Added:
incubator/tuscany/java/sca/kernel/spi/src/main/java/org/apache/
tuscany/spi/
I have updated kernel to use the new spec apis but also need to make
changes to the runtime code (the host code) and the samples. I can
either check in what I have so far which will break the runtime
module in the trunk, or I can press on until everything is converted
(which will be a much
/test to sca/testing?)
...ant
On 1/31/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote:
I was watching what you were doing with axsi2 etc. I think you've
done everything that I planned. Thanks for picking it up.
--
Jeremy
On Jan 31, 2007, at 7:08 AM, ant elder wrote:
> Are you still pl
The page is here: http://wiki.apache.org/incubator/February2007
I'm happy to pull together comments if people send them here - or
just update the page :-)
--
Jeremy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional
Couple of comments.
I'd say they're not really phases - contributing something is
independent of making changes to the assembly. The contribution
process is about adding Types to the domain (composites, classes, XSD
complexTypes, etc.) whereas the assembly is about creating/modifying/
remo
In my sandbox there is a strawman API relating to proposals to the
spec group for changes to the Java APIs for the spec. Some of these
have been accepted by the group and so I think it is time to move
this into the trunk so we can start work on implementations. I plan
to rename the existing
move where?
...ant
On 1/27/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote:
Rick pinged me tonight about problems building from the sca
directory. It turns out modules that build on their own can fail if
run as part of a reactor run as mvn gets confused over whether it
should be using the pr
On Jan 30, 2007, at 1:32 PM, Raymond Feng wrote:
Hi, Jeremy.
Thank you for the explanation.
One more thing to clarify:
Assuming I have a folder structure on the file system to host my
contribution:
/tuscany/apps/MyApp/
/tuscany/apps/MyApp/META-INF/sca/default.scdl
/tuscany/apps/MyApp/xsd/
On Jan 30, 2007, at 11:40 AM, Raymond Feng wrote:
Yes. The JAR is a packaging format understood by a
ContributionService in the domain. Based on the media type
(application/zip or application/x.tuscany.jar) this is processed
by the appropriate ContributionProcessor implementation and the
On Jan 30, 2007, at 9:44 AM, kelvin goodson wrote:
Jeremy,
thanks for your reply. A key time when this has become an issue
for me is
when applying patches. My general process has been to ensure I have a
complete clean svn extraction, build it to see if there are any
current
issues in th
d how I can change my build process to retain
this level
of confidence please?
Regards, Kelvin.
On 29/01/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote:
On Jan 29, 2007, at 6:14 AM, Rick wrote:
> Just want to make sure I understand the consequences of compiling
> from the java root with -Pal
a
bunch of independent documents. We need consistent definition across
the documents used to define the assembly which means that liberal
parsing of different documents will cause problems.
On Jan 29, 2007, at 7:39 PM, Jean-Sebastien Delfino wrote:
Comments inline.
Jeremy Boynes wrote
On Jan 29, 2007, at 5:20 PM, Raymond Feng wrote:
Hi,
I think it's better to discuss the design in the context of a
simple scenario so that we can see the whole picture. I'm giving a
try to capture what I understand. Please forgive me if there's
anything dumb and help me complete/fix it.
On Jan 29, 2007, at 3:47 PM, Meeraj Kunnumpurath wrote:
Based on the third option, I think we need to come up with the
following,
1. Classes that represent the physical model that represents the
artifacts sent to target slave runtimes for deployment.
2. A component that is responsible on th
The normative reference here is the name of the composite being used
- scdlLocation and scdlResource are things we've added to allow that
name to be resolved in a Java runtime as, to date, there is no spec-
defined mechanism for doing that. This is related to the artifact
resolution thread R
I'll assume you already have svn :-)
All you should need to build the Java version is a JDK and Maven -
you can download Maven here:
http://maven.apache.org/download.html
Once you've installed mvn, checkout the SDO tree from here
http://svn.apache.org/repos/asf/incubator/tuscany/java/sdo/
Yo
Re autowiring, I ran into a issue here trying to separate the Java
Class out of ServiceContract. There are still few places where we
assume that a ServiceContract has a corresponding Java interface - I
can deal with most of those but there are a lot of assumption in the
autowire implementat
I think this sets the wrong expectation for the snapshots. They are
not released code, they are an aid for project developers who should
be familiar with the progress of the unstable tree the snapshot
represents and that means tracking SVN. The source is there and can
just be checked out -
Jim, owe Rick better feedback than this.
Rick, then general approach here is good - creating an outbound wire
and connecting it to the inbound wire of the target service I think
is the way to go. However, you need to use the appropriate kernel
services to do this - rather than directly inst
On Jan 29, 2007, at 6:14 AM, Rick wrote:
Just want to make sure I understand the consequences of compiling
from the java root with -Pall.
As I understand it, there is no guarantee that that will work. If you
do that you are trying to build using current SVN head from
independent modules -
On Jan 27, 2007, at 2:35 PM, [EMAIL PROTECTED] wrote:
Added:
incubator/tuscany/java/sca/runtime/services/pom.xml (with props)
Thanks - I forgot to commit that :(
--
Jeremy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For
lay/~rfeng/Artifact+resolvers (You need to register with Apache
CWIKI before you can view it). It's not fully updated to reflect
the latest deployment story in the SCA spec discussion.
Please review and comment.
Thanks,
Raymond
- Original Message - From: "Jeremy Boynes"
On Jan 27, 2007, at 10:42 AM, ant elder wrote:
Does this change the moving Axis2 things around that was talked
about here:
http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200701.mbox/
[EMAIL PROTECTED]
If i went ahead and committed that change now would it get in the
way of
what y
Rick pinged me tonight about problems building from the sca
directory. It turns out modules that build on their own can fail if
run as part of a reactor run as mvn gets confused over whether it
should be using the pre-spec tree or trunk.
Unless someone beats me to it, I intend to fix that t
On Jan 26, 2007, at 1:19 PM, Raymond Feng wrote:
I have been looking into the artifact addressing and resolving. I
would like to contribute to this area once you have the two new
phases added.
Do you have anything you can send to the list for this? It would be
good be use it in the reso
At the moment the Java configuration model contains references to
artifacts associated with Java definitions - for example,
JavaImplementation references the actual Class for the
implementation. This works fine when all runtimes have access to the
applicable contribution artifacts that prov
What we're moving to on the "other side" is something like:
SCA Kernel
SCA XXX Distribution
SCA Maven Plugin for XXX
SCA Extension for XXX
It sounds like the C++ structure is evolving the same way with a
kernel, multiple distributions, extensions etc. In some ways I think
you have more in
hat is our problem and not users'.
--
Jeremy
On Jan 25, 2007, at 5:50 PM, Jean-Sebastien Delfino wrote:
Jeremy Boynes wrote:
On Jan 24, 2007, at 1:22 PM, Jean-Sebastien Delfino wrote:
The C++ runtime allows bindings and component implementation
types to share a common Tuscany namespace and
On Jan 25, 2007, at 1:35 PM, Raymond Feng wrote:
2) The component implementations express their requirements for the
property values using DataType. For java component, this can be
achieved by annotating the property with @DataType. This becomes
extensions to the componentType.
One questio
Re commonj, that isn't something that should be changing so we should
just change this to rely on the M2 version. I'll do that.
Re the sca spec, there are likely to be API changes for 1.0 so we
probably want to keep the samples using 0.95 until those stablize.
--
Jeremy
On Jan 25, 2007, at
I thought I bumped that when I tagged M2:
http://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sca/1.0-
incubator-M2/plugins/plugin.war/src/main/java/org/apache/tuscany/
plugin/war/Dependency.java
Were you looking at the branch?
--
Jeremy
On Jan 25, 2007, at 10:44 AM, ant elder wrote:
On Jan 24, 2007, at 1:22 PM, Jean-Sebastien Delfino wrote:
The C++ runtime allows bindings and component implementation types
to share a common Tuscany namespace and updates to them do not
require an update of the Kernel. We simply load the SCDL XSD files
out of each runtime extension dire
my
ant elder wrote:
On 1/24/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote:
On Jan 23, 2007, at 1:00 PM, Jean-Sebastien Delfino wrote:
> Jeremy Boynes wrote:
>> -1 on the single namespace as it couples together all the
>> extensions - we would need to create a new version of
On Jan 23, 2007, at 1:00 PM, Jean-Sebastien Delfino wrote:
Jeremy Boynes wrote:
-1 on the single namespace as it couples together all the
extensions - we would need to create a new version of the
namespace every time any extension changed its XML
I prefer a single Tuscany namespace. This
until that check can be moved to verify).
--
Jeremy
On Jan 23, 2007, at 9:30 AM, Jim Marino wrote:
On Jan 23, 2007, at 9:00 AM, Jeremy Boynes wrote:
Isn't this a problem in the verify/build phase rather than the
loader?
--
Jeremy
We already support this in the build phase. Ultim
archive.com/tuscany-dev@ws.apache.org/
msg09447.htmlthread.
..
> If CXF have found it to work for them I think it would be a great
> plan
>
>
>
> On 06/01/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
>>
>> Jim Marino wrote:
>> >
>> >
Isn't this a problem in the verify/build phase rather than the loader?
--
Jeremy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-1 on the single namespace as it couples together all the extensions
- we would need to create a new version of the namespace every time
any extension changed its XML
--
Jeremy
On Jan 23, 2007, at 4:35 AM, ant elder (JIRA) wrote:
[ https://issues.apache.org/jira/browse/TUSCANY-1053?
On Jan 23, 2007, at 1:33 AM, Meeraj Kunnumpurath wrote:
Jeremy,
I have asked whether they plan to mavenize the 2.4 release. It doesn't
look like their immediate priority. I plan to volunteer to do that for
them if they agree.
That would be great, especially for the long term. It's still
po
Are you working with the JXTA/Maven people to get this version added
to the repo?
--
Jeremy
On Jan 21, 2007, at 7:08 AM, [EMAIL PROTECTED] wrote:
Author: meerajk
Date: Sun Jan 21 07:08:51 2007
New Revision: 498349
URL: http://svn.apache.org/viewvc?view=rev&rev=498349
Log:
Added module to in
Answers inline where I think I know - hopefully Raymond can supply
more detail as needed.
On Jan 20, 2007, at 10:20 PM, Comain Chen wrote:
Thanks for your answer, it helps me a lot.
I have additional questions about databinding, hopfully any one can
give me
some hints.
1. "That makes
I don't know about "recommended" - SDO is "a" databinding in SCA/
Tuscany with certain advantages but others are also relevant. For
example, the Java spec talks about a JAX-WS representation of WSDL
interfaces and the databinding for that would be JAXB.
The goal we've had is that users shoul
I think there's a lot of history there and that we could do with a
good cleanup. In particular I think the Launcher version should
disappear all together. Also getApplicationDirectory is only there to
support something in the Spring container and can probably be
replaced as well. I've been
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
guarante
On Jan 19, 2007, at 1:29 AM, ant elder wrote:
Tuscany webapps aren't working after this change as nothing is ever
setting
the CONTEXT_ATTRIBUTE in the ServletContext so TuscanyFilter
initializes the
context to null. Is this just an oversight or as CONTEXT_ATTRIBUTE is
deprecated is it not in
[
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.
> Autow
On Jan 18, 2007, at 4:00 PM, Luciano Resende wrote:
Thanks for looking into this Jeremy,
Are you saying that distributions/sca/standalone is kind of
obsolete right
now ?
Yes. I'll remove it to cut the confusion.
What is going to be the right basic standalone distribution we
should use,
[
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 assembl
On Jan 18, 2007, at 12:35 PM, Raymond Feng wrote:
Hi, Jeremy.
I need a bit clarification: are you proposing not to release the
current kernel but "branch" (with the latest kernel code in trunk)
it instead so that the extension developers can reference stable
SNAPSHOT versions of the curre
I'd suggest copying it and changing the version to 'do-not-use-
SNAPSHOT' or something. Artifacts can be published to the SNAPSHOT
repo but there's no need to formally release as this is really a
development snapshot. It can be patched if something critical comes
up but wouldn't be intended
On Jan 17, 2007, at 3:32 PM, Jean-Sebastien Delfino wrote:
Jeremy Boynes wrote:
On Jan 13, 2007, at 2:12 PM, Jean-Sebastien Delfino wrote:
I have committed the changes under revision r495979.
I have republished corresponding snapshot jars of the spec SCA
API and the Tuscany Kernel core
On Jan 13, 2007, at 2:12 PM, Jean-Sebastien Delfino wrote:
I have committed the changes under revision r495979.
I have republished corresponding snapshot jars of the spec SCA API
and the Tuscany Kernel core module:
http://people.apache.org/repo/m2-snapshot-repository/org/osoa/sca-
api-r0.95
I'm still seeing this - what do I need to do to fix it?
--
Jeremy
On Jan 13, 2007, at 11:11 AM, Jeremy Boynes wrote:
I'm getting a download failure in tools:
Reason: Error getting POM for 'org.apache.axis2:axis2-codegen' from
the repository: Error transferring file
or
201 - 300 of 1609 matches
Mail list logo
