I've not looked at the branch lately (only just back from vacation), but I
would very much hope that there would be nothing preventing having both the
JNI and native-Java libraries in the classpath, and allowing for explicit
creation of the desired implementation of Connection / Messenger /
Hi Rob,
I believe we're thinking along the same lines.
The ServiceLoader approach does indeed only affect which implementation you
get by default. We will also allow the client to explicitly choose their
implementation if they wish, and there will be no problem with both
implmentations being
On Fri, Jan 04, 2013 at 03:49:57PM -0500, Rafael Schloming wrote:
Compared to the other bindings, it seems inconsistent for the former to
state its Perl-ness in its name, and for the latter to state its
Swig-ness.
Thoughts?
Negative on Perl.
The raw Perl extension is named
I've been working on the Java binding of proton-c and have a couple of
questions about how we're naming our various libraries.
On Linux, running make all produces the following:
bindings/ruby/cproton.so
bindings/python/_cproton.so
bindings/perl/libcproton_perl.so
bindings/libproton-swig.so (on
Phil,
The only shared-object in that list that is a proper library is
libqpid-proton.so. The others are extension modules for their various
scripting languages. I'm not 100% sure, but I believe that the naming
conventions are dictated by the scripting language's extension mechanisms.
-Ted
On Fri, Jan 4, 2013 at 11:04 AM, Ted Ross tr...@redhat.com wrote:
Phil,
The only shared-object in that list that is a proper library is
libqpid-proton.so. The others are extension modules for their various
scripting languages. I'm not 100% sure, but I believe that the naming
conventions
Thanks for the responses guys. That all makes sense.
The only change that I'd propose is therefore that the Perl and Java
bindings:
bindings/perl/libcproton_perl.so bindings/java/libproton-swig.so
... should both be renamed to libcproton.so.
Compared to the other bindings, it seems
On Fri, Jan 04, 2013 at 07:58:10PM +, Phil Harvey wrote:
Thanks for the responses guys. That all makes sense.
The only change that I'd propose is therefore that the Perl and Java
bindings:
bindings/perl/libcproton_perl.so bindings/java/libproton-swig.so
... should both be renamed to
On Fri, Jan 4, 2013 at 2:58 PM, Phil Harvey p...@philharveyonline.comwrote:
Thanks for the responses guys. That all makes sense.
The only change that I'd propose is therefore that the Perl and Java
bindings:
bindings/perl/libcproton_perl.so bindings/java/libproton-swig.so
... should both
On Fri, Jan 04, 2013 at 03:32:44PM -0500, Rafael Schloming wrote:
Given what little I know of loading JNI stuff, that seems to make sense for
Java.
FWIW, the python and ruby bindings don't ever actually expose the name of
the C extension library since in both cases we have the so-called
On Fri, Jan 4, 2013 at 3:15 PM, Darryl L. Pierce dpie...@redhat.com wrote:
On Fri, Jan 04, 2013 at 07:58:10PM +, Phil Harvey wrote:
Thanks for the responses guys. That all makes sense.
The only change that I'd propose is therefore that the Perl and Java
bindings:
Ditto for Java. From the developer's point of view, they'll simply be
using the Java interfaces in proton-api such as Connection [1].
Our current intention is that the choice of whether to use the pure Java
implementations or the proton-c-via-Swig-via-JNI one will be made using a
factory
Does that mean you won't be able to use both the C and Java implementation
simultaneously within a single JVM?
--Rafael
On Fri, Jan 4, 2013 at 4:02 PM, Phil Harvey p...@philharveyonline.comwrote:
Ditto for Java. From the developer's point of view, they'll simply be
using the Java interfaces
The in-progress code on the jni branch does not currently allow this,
although is no technical barrier to doing it. We just haven't yet decided
on the nicest api for allowing the application to choose the implementation
it wants.
The ability to mix implementations within a jvm will certainly be
14 matches
Mail list logo
