On Mar 31, 2007, at 9:11 AM, Davanum Srinivas wrote:
Let's wait and see. No clue yet. Clearly some people value their
technical prowess more than their desire to build community.
Dims,
The reason I will not be involved in the project is because my
interests and goals are different than
On Mar 29, 2007, at 10:28 AM, Jeremy Boynes wrote:
On Mar 28, 2007, at 11:29 PM, Venkata Krishnan wrote:
Hi Jeremy,
Here is a problem that most of us are facing with the Trunk and is
hindering
us to effectively contribute to the trunk. I see there is one
solution that
has been proposed
On Mar 28, 2007, at 12:51 AM, ant elder wrote:
Here's the vote on this I said [1] I'd start to get closure on this
issue.
The proposal is to have top-level pom for the Java SCA project that
enables
building all the modules together - kernel, services, runtimes,
extensions
etc, and for
Sorry for the delay, I've been out and then tied up at work...
My first comment is most of the code is organized the way you describe.
I do have several big issues with details:
1. A main tenet of the current runtime architecture is that there is
one kernel implementation capable of being
On Mar 23, 2007, at 8:52 PM, Jean-Sebastien Delfino wrote:
Davanum Srinivas wrote:
Sebastien,
Can you please explain to everyone the purpose of this svn area and
what you are planning to do here?
thanks,
dims
Dims,
In the sandbox, I am trying to demonstrate a modular Tuscany kernel
On Mar 23, 2007, at 3:29 AM, ant elder wrote:
On 3/22/07, Jeremy Boynes [EMAIL PROTECTED] wrote:
snip/
I don't think the SPI is quite as stable as Dave would like but we
should be able to improve things after alpha2. I think we should
target an SPI freeze for the beta (June you were
On Mar 23, 2007, at 5:17 AM, ant elder wrote:
I just noticed this in a recent TSS article: Mule is talking with
Tuscanyhttp://cwiki.apache.org/TUSCANY/project for an SCA
implementation. [1]. Does anyone know more about that?
If this is being considered it would be really helpful to bring it
Someone inquired about the C++ questions at the ServerSide and I
wanted to respond but can't remember where it was originally stated
due to the avalanche of emails to the list. Someone specifically
asked about the C++ programming model and if it was going to
incorporate some of the same
to quote an article Jim Marino
sent
from
Martin Fowler about Continuous Integration [1] :
Automated environments for builds are a common feature of
systems. The
Unix
world has had make for decades, the Java community developed Ant,
the .NET
community has had Nant and now has MSBuild. Make sure
This seems good +1.
Jim
On Mar 22, 2007, at 10:21 AM, Raymond Feng wrote:
+1.
I think it's in line with the proposal in my response to Meeraj.
One question: For a bundle to reference a module in the Tuscany
source tree, do we really have to copy (or use svn:externals
property) if it
Jim,
Congratulations and Thanks for a nice summary. Are you planning to
record the presentation and demo? It would be nice to have it
posted somewhere, maybe on theserverside.com?
Unfortunately, I don't think I can publish the slides on my own as it
is part of the Serverside
Hi Meeraj
From my perspective having demonstrable code in June would be spot
on as
I have to speak on SCA then and would consider a demo if we could
do it.
Maybe we can even get something earlier - I'm also speaking at JavaOne.
I don't have the knowledge yet to comment on the details
On Mar 22, 2007, at 1:44 PM, Kevin Williams wrote:
Jim and Meeraj,
Congratulations! Any chance the presentation was taped?
--Kevin
Thanks,
I don't think it was. I mentioned I will try to see if I can reprint
copies of the slides. BTW, I wanted to also say Meeraj and Jeremy
were the
On Mar 21, 2007, at 3:53 AM, Davanum Srinivas wrote:
we decided to abandon...was there a VOTE? Please refresh my memory.
Yes, that was when we voted to move Chianti to trunk.
Jim
-
To unsubscribe, e-mail: [EMAIL
Hi,
We just finished the ServerSide demo and I figured I send a mail to
the list outlining how it went...
We had the slot following the opening keynote and were up against Rod
(Spring) and Patrick (OpenJPA) as the other two talks. I was
surprised to find that the ballroom was pretty
On Mar 20, 2007, at 7:23 AM, Jeremy Boynes wrote:
The current model is based on simple POJOs. Sebastien has proposed
rewriting the configuration model to be based on interfaces with
separate implementation and factory classes. This will have a major
impact on the kernel code and all
On Mar 20, 2007, at 10:45 PM, Luciano Resende wrote:
Hi Sebastien
My understanding is that these are separate modules that are not
going to
destabelize the trunk at the moment. My personal opinion is that it
would be
OK to have this work done in the trunk as most of new work is being
On Mar 19, 2007, at 11:04 AM, Raymond Feng wrote:
The code in trunk was using model as the package name. When I
merged the changes, I decided to leave them as is and defer the
refactoring to a later point.
FYI, The reason why it uses that is there are references to the class
from
On Mar 19, 2007, at 11:11 AM, ant elder wrote:
Ok so how about I move all the idl related classes from model to
org.apache.spi.idl? I was thinking about that anyway as part of the
IDL
refactoring that was discussed a while back.
+1 as long as you don't introduce circular references.
On Mar 19, 2007, at 10:40 PM, Jean-Sebastien Delfino wrote:
Jean-Sebastien Delfino wrote:
I'd like to start a discussion on how we could componentize our
SCA runtime kernel. I posted two diagrams on our Wiki at http://
cwiki.apache.org/confluence/display/TUSCANY/Componentizing+our
+runtime
On Mar 16, 2007, at 4:16 AM, ant elder wrote:
With trying to get containers and bindings going in the trunk again
and it
looks like with all the core changes the SPI is a little out of
date now.
Eg, there's classes like InsanceWrapperBase in the core that could
be in the
SPI,
On Mar 16, 2007, at 4:25 PM, Luciano Resende wrote:
I think there has been various threads talking about the contribution
services on the dev mailing list. Jeremy suggested having a
contribution
tool (command line and plugin) [1] and there was some other
discussions
around integrating
On Mar 16, 2007, at 4:58 PM, Jeremy Boynes wrote:
On Mar 16, 2007, at 4:50 PM, Jim Marino wrote:
On Mar 16, 2007, at 4:25 PM, Luciano Resende wrote:
After thinking about it, I'm starting to think that a better
place for it is
under /java/sca/services.Thoughts ?
That was exactly why I
I've seen it. Thanks. The standalone server is nice, but I'm
looking for a client, similar to what we had in Tuscany M1. I want
to be able to write the main method of a client program, set up the
Tuscany environment myself from the main method, and start that
program like any other Java
I've go most of the Wire, InvocationChain, ProxyService, and
InvocationChain infrastructure working using the new federated/
physical model (r518500). I had to add the following additional
metadata:
PhysicalWireSourceDefinition#conversational
On Mar 15, 2007, at 4:29 PM, Meeraj Kunnumpurath wrote:
Hi,
I have been trying to list the outstanding tasks to get federation
done and have the demo working for TSS. These are the things I have
in my list,
1. Contribution service on the controller
2. Assembly service on the controller
On Mar 15, 2007, at 5:05 PM, Luciano Resende wrote:
I can continue to contribute on the following items, as I have already
started them:
* contribution store (and maybe artifact redistribution)
* contribution tool (command line and plugin?)
BTW, we will need the assembly services for the
In order to allow for attachment of optimized wires on a source
component, I'm going to slightly change the WireAttacher interface to
pass in the target Component as well as the source Component during
the attach operation. In the case of Java implementation types, this
will allow the
On Mar 12, 2007, at 8:10 PM, Jim Marino wrote:
With the connector changes and move to using only Component types
for extensions, I think we can safely get rid of TargetInvoker. On
Component, we will have:
void attachWire(Wire wire, PhysicalWireSourceDefinition
defintion);
void
I don't but I'm on an Intel dual core so it may be a race condition.
What type of CPU are you using?
Jim
On Mar 13, 2007, at 3:12 AM, ant elder wrote:
When building the standalone module in trunk I get intermittently
get an
InterruptedException which causes the test to hang. I've not been
On Mar 13, 2007, at 5:58 AM, Meeraj Kunnumpurath wrote:
Sure, I will do that. Cuurently attach method is agnostic to
whether it
is forward or callback. If we have specific ones, would the signature
change?
No I think the signature would be the same but some of the meta-data
passed as
On Mar 13, 2007, at 12:28 PM, Jeremy Boynes wrote:
On Mar 13, 2007, at 4:55 AM, Jim Marino wrote:
Hi Meeraj,
I've been working on getting the WireAttachers going for
PhysicalComponentDefinitions. On PhysicalWireDefinition, I've
added PhysicalWireSourcetDefinition
I would like to start thinking about the next release of kernel.
Based on the work being done around federation, it seems that multi-
VM support is the key feature we should look to enable. This will
allow us to demonstrate the high-value areas of SCA, particularly
around distributed
On Mar 11, 2007, at 4:43 PM, Jean-Sebastien Delfino wrote:
I'd like to start a discussion on how we could componentize our SCA
runtime kernel. I posted two diagrams on our Wiki at http://
cwiki.apache.org/confluence/display/TUSCANY/Componentizing+our
+runtime to help start the discussion.
. The prototyping could be done in
the integration branch (I wasn't quite sure if Sebastien was
proposing this), or in some other place.
I've added a few comments inline below.
Simon
Jim Marino wrote:
On Mar 11, 2007, at 4:43 PM, Jean-Sebastien Delfino wrote:
I'd like to start a discussion on how we
I'm starting to get stuck into the final pieces for having the
Connector support federated deployment. I plan to implement the
following algorithm in the FederatedDeployer to deploy a
PhysicalChangeSet:
1. For each resource definition, build resource
2. For each PhysicalComponentDefinition
On Mar 12, 2007, at 12:57 PM, Bert Lamb wrote:
On 3/10/07, ant elder [EMAIL PROTECTED] wrote:
I think we really have to do something as its way to hard to get
things
built right now and I'm positive this is putting people off.
It is actively putting me off right now. The build problems
On Mar 12, 2007, at 1:36 PM, Meeraj Kunnumpurath wrote:
Jim,
Some of this is already implemented in the federated deployer.
Yep I saw the building dispatch in there :-)
Jim
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For
On Mar 12, 2007, at 2:15 PM, Luciano Resende wrote:
Jim said:
The trunk has been quite stable for some time.
What's your scope of trunk ? Following the instructions in
https://svn.apache.org/repos/asf/incubator/tuscany/java/
BUILDING.txt nothing
get's built. Trying to build the sca
On Mar 12, 2007, at 3:00 PM, ant elder wrote:
I agree with what Bert are Luciano are saying and I'm having the same
problems while trying to get the Axis2 binding going again in
trunk. Many
people have been having trouble with this for months now and have been
coming up with their own
On Mar 12, 2007, at 3:57 PM, Jean-Sebastien Delfino wrote:
[snip]
Jim Marino wrote:
-1 this forces all extensions to use the latest trunk, which
proved unworkable and which seems to be causing problems in the
integration branch with all the profile changes and build breaks.
FYI
I disagree that this proved unworkable, could you give some concrete
examples of how you think its been unworkable so we can way those
against
the benefits a full top-level build provides?
Don't you remember all of the build breaks we had in the past or the
issues we had with the releases?
With the connector changes and move to using only Component types for
extensions, I think we can safely get rid of TargetInvoker. On
Component, we will have:
void attachWire(Wire wire, PhysicalWireSourceDefinition defintion);
void attachWire(Wire wire, PhysicalWireTargetDefinition
On Mar 9, 2007, at 8:07 AM, Jeremy Boynes wrote:
Subclassing in the model makes sense to me.
I don't think anything would need to be added to AbstractSCAObject
- by the time we get to the runtime all of the intents and
policySets should have been processed and converted into wires with
On Mar 9, 2007, at 9:44 AM, haleh mahbod wrote:
What happens in a single node case? Will the controller always be
present?
A single-VM or runtime physical topology is just a degenerate case of
the distributed one. In other words, the controller and slave will
happen to be in the same
FYI,
I've added a project to start work on the Hessian binding. Getting
RMI in or a WS binding would also be good if someone is interested in
starting that.
Jim
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional
On Mar 9, 2007, at 4:13 PM, Meeraj Kunnumpurath wrote:
I can start on the RMI. Also, one of my colleagues at work at
written an
abstract framework for Hessian binding. It is mainly used for a
Hessian
Mule connector, however much of the code is pretty agnostic to Mule.
Would they be
On Mar 9, 2007, at 3:02 PM, ant elder wrote:
On 3/9/07, ant elder [EMAIL PROTECTED] wrote:
On 3/9/07, Jim Marino [EMAIL PROTECTED] wrote:
FYI,
I've added a project to start work on the Hessian binding.
Isn't Hessian GPL?
Ok sorry maybe not, the Caucho download page talks about GPL
Ok, I'll have a go at catching up the Axis2 WS binding in the trunk
to what
we have in the integration branch. Whats the status of the WSDL IDL
in the
trunk right now?
...ant
I think getting Axis updated would be great. The WSDL IDL compiles
but I haven't personally tested it. Let
On Mar 8, 2007, at 3:08 PM, Meeraj Kunnumpurath wrote:
Hi,
I have been working on the framework to enable federated
heterogeneous deployment of a logical assembly across one or more
physical runtimes. I was wondering whether we can get an end-to-end
story working that demonstrates the
am also attaching the war file. I have deleted the lib files from
the war.
thanks,
Muhammad Waseem
From: Jim Marino [mailto:[EMAIL PROTECTED]
Sent: Wed 3/7/2007 9:47 PM
To: tuscany-dev@ws.apache.org
Subject: Re: tyring to run spring application
On Mar 7, 2007, at 9:47 AM, Waseem, Muhammad
On Mar 7, 2007, at 9:04 AM, Ignacio Silva-Lepe wrote:
I have a couple of questions about the http.jetty service.
First, I am assuming that this service is intended to be kept
around and
not deprecated, but let me know if this is not the case.
If that is the case, then I wonder what the
If that helps, I have been able to use the Jetty service in the
integration branch as a ServletHost to expose Web Services with the
Axis2 binding. To see this working you can take a look at the sca/
extensions/axis2/samples/helloworld-ws sample.
--
Jean-Sebastien
Cool, do you want to
I've been working on getting the Physical marshalling and build
infrastructure integrated with the connector. In order to do this, I
changed the way types are being tracked on
PhysicalOperationDefinition. Instead of directly referencing the
type's class, I changed it to track the fully
Type below...
On Mar 7, 2007, at 11:55 AM, Jim Marino wrote:
I've been working on getting the Physical marshalling and build
infrastructure integrated with the connector. In order to do this,
I changed the way types are being tracked on
PhysicalOperationDefinition. Instead of directly
On Mar 7, 2007, at 9:59 AM, Mike Edwards wrote:
Folks,
With my spec hat on - the NAMES of the specs ain't going to change.
However, some of the FILES belonging to the spec are VERY likely to
change before publication. I know FOR SURE that sca-core.xsd is
going to change from the
On Mar 7, 2007, at 1:50 PM, Meeraj Kunnumpurath wrote:
Jim,
Is the MPL available in the registry. Or is it going to be the app
CL looked up from the registry and the MPCL created from the looked
up app CL and the system CL?
Ta
Meeraj
It should be the Multiparent CL from the
When we convert over to the federated marhsallers, I think we can get
rid of AtomicComponent and just have Component. To do this, we would
need to move some of the lifecycle getters such as conversational
lifetime, etc. to Component. The other change we would need to do is
have
On Mar 7, 2007, at 9:47 AM, Waseem, Muhammad ((CA - Toronto)) wrote:
Hi,
I am trying to run a spring application under tomcat 5.5.17 but I
am getting UnRecognizedElement exception. I am using tuscany-
incubating-M2. can somebody tell me how I can install spring
extension?
thanks,
+1 from me.
A side comment, this will give us the ability to init a single
runtime instance in a method annotated with a Junit @BeforeClass
annotation and reuse it across multiple test methods. I think it
will be interesting for integration tests in particular.
Raymond, are you going to
On Mar 7, 2007, at 9:57 PM, Meeraj Kunnumpurath wrote:
A related question I had was, wouldn't most of the logic in
JavaComponent etc for handling properties, introspection etc go
into the
generated instance factory bytecode?
I believe so. I just stubbed out the methods from
On Mar 6, 2007, at 11:50 AM, Kevin Williams wrote:
I modified the DAS overview page to include a link to the RDB DAS
User's Guide since, with the move to cwiki, there was no path to
this documentation.
Sorry! I must have missed the link.
Jim
On Mar 6, 2007, at 6:26 PM, haleh mahbod wrote:
Jim,
Thanks for the cwiki update. It looks like we lost all the C++ pages.
Haleh
Sorry, I just linked to the existing SCA C++ page on the wiki which
was apparently blank :( The other sub-project C++ pages I believe
have already been
On Mar 6, 2007, at 11:13 AM, Raymond Feng wrote:
Hi,
I think we used r0.95 in M2 but SCA spec 0.95 was published in that
case. Now we use r1.0 ahead of the official SCA 1.0 spec. If we
feel 1.0.1-incubating could be used to fix minor issuesin our
release to catch up the final SCA 1.0 if
On Mar 6, 2007, at 7:12 PM, Jeremy Boynes wrote:
On Mar 6, 2007, at 7:03 PM, Jim Marino wrote:
Putting my spec hat on, I can pretty confidently say the chances
of content changes to the specs are remote at best. I'd
characterize 'remote' as the possibility of getting 20 lawyers
Now that we have the Maven iTest plugin in place, I'd like to get a
continuous integration server as well as a nightly build in place.
I've included a build status link in the cwiki (http://
cwiki.apache.org/confluence/display/TUSCANY/Java+SCA+Kernel) to
http://www.buildtuscany.com/.
On Mar 5, 2007, at 5:03 PM, Jeremy Boynes wrote:
I have posted release candidates of the 2.0-alpha kernel release on
my home directory at people.apache.org and uploaded the artifacts
to the maven repo for:
SCA Parent POM 1.0-incubating
SCA Composite Plugin 1.0-incubating
SCA Kernel
[
https://issues.apache.org/jira/browse/TUSCANY-897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jim Marino updated TUSCANY-897:
---
Fix Version/s: (was: Java-SCA-Mx)
Java-SCA-2.0-Alpha
BPEL container based
[
https://issues.apache.org/jira/browse/TUSCANY-616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jim Marino closed TUSCANY-616.
--
Resolution: Fixed
Fix Version/s: (was: Java-SCA-Mx)
Java-SCA-2.0-Alpha
[
https://issues.apache.org/jira/browse/TUSCANY-810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jim Marino closed TUSCANY-810.
--
Resolution: Fixed
Fix Version/s: (was: Java-SCA-Mx)
Java-SCA-2.0-Alpha
[
https://issues.apache.org/jira/browse/TUSCANY-896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jim Marino closed TUSCANY-896.
--
Resolution: Fixed
java.lang.IndexOutOfBoundsException trying when there is no default service
[
https://issues.apache.org/jira/browse/TUSCANY-544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jim Marino updated TUSCANY-544:
---
Fix Version/s: (was: Java-SCA-Future)
Tooling-Next
WSDL2Java should support
[
https://issues.apache.org/jira/browse/TUSCANY-1019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jim Marino updated TUSCANY-1019:
Fix Version/s: (was: Java-SCA-Future)
Tooling-Next
Affects
[
https://issues.apache.org/jira/browse/TUSCANY-1137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jim Marino updated TUSCANY-1137:
Fix Version/s: (was: Java-SCA-Future)
Tooling-Next
WSDL2Java tool should
[
https://issues.apache.org/jira/browse/TUSCANY-1142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jim Marino updated TUSCANY-1142:
Fix Version/s: (was: Java-SCA-Future)
(was: Java-SCA-integration
[
https://issues.apache.org/jira/browse/TUSCANY-199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jim Marino updated TUSCANY-199:
---
Fix Version/s: (was: Java-SCA-Future)
Java-BigBank-Future
Affects
[
https://issues.apache.org/jira/browse/TUSCANY-751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jim Marino updated TUSCANY-751:
---
Fix Version/s: (was: Java-SCA-Future)
Website-Enhancements
[
https://issues.apache.org/jira/browse/TUSCANY-824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jim Marino updated TUSCANY-824:
---
Fix Version/s: (was: Java-SCA-2.0-Alpha)
Java-SCA-2.0
DataBinding
[
https://issues.apache.org/jira/browse/TUSCANY-610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jim Marino updated TUSCANY-610:
---
Component/s: Java SCA OSGi Runtime
Initial OSGi support effort
As prep fro the release I tried to clean up the JIRA issues a bit. I
created a version for the alpha kernel as well as started adding
component tags for extensions that will be independently released in
the future such as Spring and JPA. I also tried to place issues in
proper categories,
+1 Jim
On Mar 3, 2007, at 6:16 PM, Jeremy Boynes wrote:
Please vote to approve the release of the sca-api's for r1.0 of the
specification. This is the API code that we recently reviewed but
please vote again to confirm the release.
[tag]
[
https://issues.apache.org/jira/browse/TUSCANY-922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jim Marino updated TUSCANY-922:
---
Fix Version/s: (was: Java-SCA-2.0-Alpha)
Java-SCA-2.0
Target instance
[
https://issues.apache.org/jira/browse/TUSCANY-1039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jim Marino updated TUSCANY-1039:
Component/s: (was: Java SCA Kernel)
Java SCA Axis Binding
[
https://issues.apache.org/jira/browse/TUSCANY-1032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jim Marino updated TUSCANY-1032:
Affects Version/s: Java-SCA-2.0
Java-SCA-2.0-Alpha
Fix Version/s
[
https://issues.apache.org/jira/browse/TUSCANY-922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jim Marino updated TUSCANY-922:
---
Affects Version/s: Java-SCA-2.0
Target instance is not cached in reference proxy
[
https://issues.apache.org/jira/browse/TUSCANY-?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jim Marino updated TUSCANY-:
Fix Version/s: Java-SCA-2.0
Affects Version/s: Java-SCA-2.0
Java
[
https://issues.apache.org/jira/browse/TUSCANY-695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jim Marino reassigned TUSCANY-695:
--
Assignee: Jeremy Boynes
JavaComponentTypeLoader.load() returns PojoComponentType which isn't
[
https://issues.apache.org/jira/browse/TUSCANY-1005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jim Marino updated TUSCANY-1005:
Affects Version/s: (was: Java-SCA-Future)
Java-M2
Build failure
[
https://issues.apache.org/jira/browse/TUSCANY-632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jim Marino closed TUSCANY-632.
--
Resolution: Fixed
In sca-core.xsd, top level component element should be removed
[
https://issues.apache.org/jira/browse/TUSCANY-1090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jim Marino updated TUSCANY-1090:
Fix Version/s: Java-SCA-Axis-Future
A service with two operations exposed over a WS binding
Project: Tuscany
Issue Type: Bug
Components: Java SCA Spring Extension
Affects Versions: Java-SCA-Spring-2.0-Alpha
Reporter: Jim Marino
Fix For: Java-SCA-Spring-2.0-Alpha
--
This message is automatically generated by JIRA.
-
You can reply
FYI,
I've cut-over the site to using the cwiki which should go live as
soon as the files replicate. I left the old site files in place
under /site as there are still a few wiki links which point back to
them (mainly the download pages). I'll try and convert those over as
well over the
On Mar 3, 2007, at 2:33 AM, ant elder wrote:
Currently the axis2 binding scdl includes the idl.wsdl scdl [1] to fix
problems with inter-extension dependencies, but it looks like this
causes
two instances of the wsdl registry to be created. This causes
intermittent
failures in the axis2
[
https://issues.apache.org/jira/browse/TUSCANY-640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jim Marino closed TUSCANY-640.
--
Resolution: Fixed
Fix Version/s: (was: Java-SCA-M3)
Java-SCA-2.0-Alpha
[
https://issues.apache.org/jira/browse/TUSCANY-1069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jim Marino closed TUSCANY-1069.
---
Resolution: Fixed
The spec has removed locateService()
Cannot access default service
[
https://issues.apache.org/jira/browse/TUSCANY-910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jim Marino closed TUSCANY-910.
--
Resolution: Fixed
The spec has removed this API.
CurrentCompositeContext.getContext() returns
[
https://issues.apache.org/jira/browse/TUSCANY-1080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jim Marino updated TUSCANY-1080:
Fix Version/s: (was: Java-SCA-M3)
Java-SCA-2.0-Alpha
Affects
[
https://issues.apache.org/jira/browse/TUSCANY-1071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jim Marino closed TUSCANY-1071.
---
Resolution: Fixed
Fix Version/s: (was: Java-SCA-M3)
Java-SCA-2.0
[
https://issues.apache.org/jira/browse/TUSCANY-291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jim Marino updated TUSCANY-291:
---
Fix Version/s: (was: Java-SCA-M3)
Java-SCA-2.0-Alpha
[
https://issues.apache.org/jira/browse/TUSCANY-862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jim Marino closed TUSCANY-862.
--
Resolution: Fixed
The spec has removed this API.
NPE when doing
1 - 100 of 1205 matches
Mail list logo
