ant elder wrote:
On Tue, Jul 20, 2010 at 6:07 AM, Jean-Sebastien Delfino
<[email protected]> wrote:
Jean-Sebastien Delfino wrote:
Hi all,
I'm starting to code a simple/minimalistic implementation.python extension
for Python components on the Java runtime, similar to what's working on the
native runtime [1].
It's really basic. Component business methods are written as Python
functions, references and properties are represented as Python function
objects and passed as function arguments, and JSON or XML structured data
are just represented as Python tuples.
I've started to write code for it this afternoon, and implementing it on
top of the Java runtime is looking easy so far. I'm planning to commit a
strawman in the next few days or next weekend, depending on how much spare
time I find to hack on this.
[1]
http://svn.apache.org/repos/asf/tuscany/sca-cpp/trunk/samples/store-python/
Here's an update. I quickly ran into a number of issues and realized that
the Java runtime currently assumes the presence of Java business interfaces
and typed Java objects in a number of areas, and that working with no Java
at all (e.g just Python, or just BPEL) is not so easy at the moment.
Here are a number of scenarios I've looked at:
- Atom binding flowing entries to a BPEL or Python scripting component
- JSON-RPC binding with a BPEL or scripting component
- a BPEL component and a scripting component wired together
- a scripting component not using a Java interface to type its service,
instead using a completely dynamic interface.
The first issue I've run into is that the latest JSON-RPC binding
implementation, based on jabsorb, only works if Java classes are available
for all the JSON compound types (on both service and reference side) and
components use Java interfaces (on the reference side in particular, where
the current code attempts to use the operation's Java method! to initialize
the jabsorb client...)
I'm not sure if anybody has tried to use the JSON-RPC binding with a
WSDL-typed component, but that's not working :)
So, I'm starting to experiment with, and really hack... the runtime, some of
the bindings and invokers, to explore what it would take to get more dynamic
components with no Java interfaces really working.
I may also have to tweak the databinding mediator which currently assumes
that the target of a mediation has pre-defined types for all its arguments,
which is not going to be the case for a dynamic operation.
I'm doing that in a sandbox 'dynamic' branch [1] for now as obviously my
hack changes are breaking changes not suitable for trunk, but I'll try to
update the group as I make some progress with this experiment.
Is there really no way you can try to do this in trunk? We have
already got code to support dynamic interfaces in trunk, if it has
bugs it would be vastly preferable to fix them in trunk than in a
fork. I'd much prefer that we first try to fix up the dynamic
interface support in trunk, at least initially, and only if/when we
hit some issue that really is hard to fix without disrupting trunk
then look at options like branches.
I don't see a problem with using a sandbox branch to experiment.
IMO a sandbox is a good way to show experimental work, without
disturbing the work in trunk as it looks like people are trying to fix
it and achieve OASIS compliance.
Also, it's really not easy to see if my experiments to enable a more
dynamic behavior are breaking something at this point, as I'm not able
to get a successful build even without my changes (see below).
On the other hand, the changes are in the sandbox for all to see now,
and if people are OK with these changes in trunk, I'll be happy to make
them there. Let me know... I'd like to hear from others too.
It'd be nice to get any technical comments on the issues I've started to
describe in this thread (I've seen no comments so far):
- assumption that there's a Java interface even for a dynamic service
- JSON-RPC binding not using the databinding framework
- if anybody has tried WSDL-typed components with various bindings
- how the data-mediator should work in presence of dynamic operations
The following modules break for me (Ubuntu 9.10, OpenJDK 1.6.1 from the
Ubuntu distro). This looks like a moving target, too. A few days ago
module "Apache Tuscany SCA Specification Compliance Tests Java CI" was
building OK, and IIRC I had one or two less failures in itests:
[INFO] Apache Tuscany SCA Tomcat Tribes Based EndPoint Registry FAILED
[3.146s]
[INFO] Apache Tuscany SCA Sample Helloworld BPEL ............. FAILED
[3.902s]
[INFO] Apache Tuscany SCA Sample Helloworld JAX-RS ........... FAILED
[1.229s]
[INFO] Apache Tuscany SCA Sample JMS HelloWorld in a WebApp .. FAILED
[2.374s]
[INFO] Apache Tuscany SCA Sample Helloworld Javascript Client FAILED
[1.173s]
[INFO] Apache Tuscany SCA Sample Helloworld JSP .............. FAILED
[0.812s]
[INFO] Apache Tuscany SCA Sample Helloworld using Stripes .... FAILED
[2.828s]
[INFO] Apache Tuscany SCA Sample Helloworld Servlet .......... FAILED
[0.511s]
[INFO] Apache Tuscany SCA Sample Launcher Embedded JSE ....... FAILED
[7.474s]
[INFO] Apache Tuscany SCA Sample Launcher Embedded OSGi ...... FAILED
[12.691s]
[INFO] Apache Tuscany SCA Sample Launcher Embedded OSGi using base jar
FAILED [5.598s]
[INFO] Apache Tuscany SCA iTest Distribution Legal Checks .... FAILED
[9.341s]
[INFO] Apache Tuscany SCA iTest Distribution Contribution binding-sca
Calculator FAILED [1.552s]
[INFO] Apache Tuscany SCA iTest Distribution Contribution binding-ws
Calculator FAILED [1.528s]
[INFO] Apache Tuscany SCA iTest Distribution Contribution binding-rmi
Calculator FAILED [1.241s]
[INFO] Apache Tuscany SCA iTest Distribution contribution
implementation-java Calculator FAILED [0.698s]
[INFO] Apache Tuscany SCA iTest Distribution Launcher Embedded JSE
FAILED [1.043s]
[INFO] Apache Tuscany SCA iTest Distribution Launcher Embedded OSGi
FAILED [0.676s]
[INFO] Apache Tuscany SCA iTest Nodes One JVM Using Tribes Registry
FAILED [4.981s]
[INFO] Apache Tuscany SCA iTest Nodes binding.sca Using Hazelcast
Registry FAILED [48.574s]
[INFO] Apache Tuscany SCA iTest Policies ..................... FAILED
[4.201s]
[INFO] Apache Tuscany SCA Specification Compliance Tests Assembly
FAILED [1:09.669s]
[INFO] Apache Tuscany SCA Specification Compliance Tests Java CI FAILED
[25.363s]
Are others seeing the same build failures?
--
Jean-Sebastien
