[ http://issues.apache.org/jira/browse/TUSCANY-61?page=all ]
ant elder reassigned TUSCANY-61:
Assign To: ant elder
?WSDL on WS binding entryPoints fails
-
Key: TUSCANY-61
URL:
[ http://issues.apache.org/jira/browse/TUSCANY-61?page=all ]
ant elder closed TUSCANY-61:
Resolution: Fixed
Applied patch
?WSDL on WS binding entryPoints fails
-
Key: TUSCANY-61
URL:
Axis2 WS binding support for entryPoint without pre-existing WSDL
--
Key: TUSCANY-120
URL: http://issues.apache.org/jira/browse/TUSCANY-120
Project: Tuscany
Type: Improvement
Components: Java SCA
When tuscany was dropped in svn, I had written a new binding for ServiceMix.
I'm in the process of updating to latest tuscany svn head but it seems lots
of things have changed.
I'm basing the new code on the axis2 binding, but the problem i 'm facing
is my binding.jbi element is not recognized
I believe they based the integration on what was there prior to the
introduction of the new core architecture, including aggregates and
builders. If I recall correctly, TuscanyModuleComponentContextImpl
was used, which no longer exists. The best place to start may be to
look at some of
Jeremy Boynes wrote:
This directory contains the seed code from BEA and IBM. Things have
moved on quite a bit since then so I would like to suggest we remove
this code from the tree - old versions can still be found in the SVN
history if needed. This tree has been modified so no longer
Guillaume Nodet wrote:
Thanks, that was exactly what I was looking for. I bet the line
SDOUtil.registerStaticTypes(ScdlFactory.class);
will save me :)
The code is available at
http://svn.apache.org/repos/asf/incubator/servicemix/trunk/servicemix-sca/
but as Jim just said, it is based
Hi,
I wanted to raise the issue of how projects are promoted to the
core set of projects in the Java SCA runtime. IMO adding a project
to java/sca is a commitment by the community for long-term support.
Because of this, I would like to propose that prior to promoting a
project to
I really would like to make a distinction here between source form
documents and final form documents.
I agree that anything placed on the website as a final form document
should be in a generally acceptable open form. HTML, Maven Xdoc,
PDF, for example. Word documents are NOT acceptable as
Looking through parts of the code and I notice
ModuleScopeContext.start() does not set
lifecycleState to RUNNING
Have notice no issues with it, just curious it doesn't.
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection
Yes, RUNNING is set when the module scope event starts (see onEvent
(int type, Object key) ). This may be a bit confusing, in which case
we could change the name.
Jim
On Mar 15, 2006, at 10:04 AM, rick rineholt wrote:
Looking through parts of the code and I notice
Thanks Jim,
Maybe a comment would suffice? Tough to pick up.
Jim Marino wrote:
Yes, RUNNING is set when the module scope event
starts (see onEvent(int
type, Object key) ). This may be a bit confusing, in
which case we could
change the name.
Jim
On Mar 15, 2006, at 10:04 AM, rick
Mike Edwards wrote:
I really would like to make a distinction here between source form
documents and final form documents.
I agree that anything placed on the website as a final form document
should be in a generally acceptable open form. HTML, Maven Xdoc,
PDF, for example. Word documents
A couple of us had an offline chat about what the format of data would
be exchanged on the wire during an interaction between a client and a
provider. The spur for this was the JSON binding Ant was working on
which has no obvious affinity to XML.
Another issue related to this has been about
On Mar 15, 2006, at 3:37 PM, Jeremy Boynes wrote:
A couple of us had an offline chat about what the format of data would
be exchanged on the wire during an interaction between a client and a
provider. The spur for this was the JSON binding Ant was working on
which has no obvious affinity to
Jeremy did you start this or do you want me to do it?
Jim
On Mar 8, 2006, at 1:53 PM, Jeremy Boynes wrote:
I'm not quite sure what the autowire algorithm is but the best I've
figured out is:
* The root RuntimeContext autowires to itself for services it provides
and if not found delegates
Jim Marino wrote:
Jeremy did you start this or do you want me to do it?
I have not started yet - if you have time that would be great.
--
Jeremy
17 matches
Mail list logo