Re: inconsistent proton library names?
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 / whatever (which I'd probably suggest be done via a factory rather explicit construction, but that's just personal taste). I would hope the Service Loader would only affect the implementation created by *default* from a factory -- Rob On 4 January 2013 22:54, Phil Harvey p...@philharveyonline.com wrote: 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 nice when writing interoperability tests. Phil On Jan 4, 2013 9:16 PM, Rafael Schloming r...@alum.mit.edu wrote: 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.com wrote: 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 instantiated by a java.util.ServiceLoader. The decision will therefore depend on your runtime classpath. Client code will not have a build time dependency on the Swig/JNI layer. [1] http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-j/proton-api/src/main/java/org/apache/qpid/proton/engine/Connection.java On 4 January 2013 20:40, Darryl L. Pierce dpie...@redhat.com wrote: 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 buttercream frosting layer that wraps the raw C extension module. I would hope we'd have something similar for perl and Java so that these names shouldn't ever be visible to users. Per does. It uses qpid::proton namespace for the Message and Messenger classes. -- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/
Re: inconsistent proton library names?
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 used in the same proccess (this will be handy for writing interoperability tests). Phil On 7 January 2013 08:37, Rob Godfrey rob.j.godf...@gmail.com wrote: 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 / whatever (which I'd probably suggest be done via a factory rather explicit construction, but that's just personal taste). I would hope the Service Loader would only affect the implementation created by *default* from a factory -- Rob On 4 January 2013 22:54, Phil Harvey p...@philharveyonline.com wrote: 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 nice when writing interoperability tests. Phil On Jan 4, 2013 9:16 PM, Rafael Schloming r...@alum.mit.edu wrote: 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.com wrote: 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 instantiated by a java.util.ServiceLoader. The decision will therefore depend on your runtime classpath. Client code will not have a build time dependency on the Swig/JNI layer. [1] http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-j/proton-api/src/main/java/org/apache/qpid/proton/engine/Connection.java On 4 January 2013 20:40, Darryl L. Pierce dpie...@redhat.com wrote: 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 buttercream frosting layer that wraps the raw C extension module. I would hope we'd have something similar for perl and Java so that these names shouldn't ever be visible to users. Per does. It uses qpid::proton namespace for the Message and Messenger classes. -- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/
Re: inconsistent proton library names?
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 cproton_perl because otherwise Cmake fails. That's because we already have a target named cproton and changing Perl to that will cause a name collision. And, anyway, the output of Cmake isn't used to distribution the Perl language bindings. Those are distributed as the perl.i file, Makefile.PL, various license and doc files, and the qpid::proton namespace classes. When that's installed, a proper library is generated for Perl to use. Hmm, this doesn't seem to quite be the case. The cmake build does in fact install the swig generated files, i.e. libcproton_perl.so, and cproton_perl.pm, however it does not install the qpid::proton namespace classes. Sorry, I wasn't referring to what the Cmake system installs there. I was referring to what a packaging system would consume when creating the binaries that are installed on a system. -- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ pgpgmE9Gpd4j0.pgp Description: PGP signature
inconsistent proton library names?
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 JNI branch only) libqpid-proton.so === 1. Naming conventions All things being equal, we should adopt a consistent approach regarding: - whether to put a lib prefix on the file name (my preference is to always do this) - whether the language name should appear in the bindings libraries. I'm guessing that all things are *not* equal, and that we have deliberately named the bindings differently for some reason. Can anyone enlighten me? 2. The lib prefix on old cmake versions Regarding the lib prefix, I am using an old version of cmake (v2.6) which does not add the prefix by default. I can add 'set_target_properties(proton-xxx PROPERTIES PREFIX lib)' as a workaround. This still works ok on newer cmake versions. Unfortunately I think this will force Windows dll's to have the lib prefix, which is undesireable. Can anyone advise on the best approach? I'm not a cmake expert. Thanks Phil
Re: inconsistent proton library names?
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 01/04/2013 10:47 AM, Phil Harvey wrote: 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 JNI branch only) libqpid-proton.so === 1. Naming conventions All things being equal, we should adopt a consistent approach regarding: - whether to put a lib prefix on the file name (my preference is to always do this) - whether the language name should appear in the bindings libraries. I'm guessing that all things are *not* equal, and that we have deliberately named the bindings differently for some reason. Can anyone enlighten me? 2. The lib prefix on old cmake versions Regarding the lib prefix, I am using an old version of cmake (v2.6) which does not add the prefix by default. I can add 'set_target_properties(proton-xxx PROPERTIES PREFIX lib)' as a workaround. This still works ok on newer cmake versions. Unfortunately I think this will force Windows dll's to have the lib prefix, which is undesireable. Can anyone advise on the best approach? I'm not a cmake expert. Thanks Phil
Re: inconsistent proton library names?
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 are dictated by the scripting language's extension mechanisms. That's correct, at least for ruby and python the C extension import mechanism searches for module-name.so, and the reason there is an extra underscore in the python case is that swig autogenerates python wrapper code and so there are actually two modules produced by swig. The cproton module (pure python, but generated), and the _cproton module, a C extension module that is an implementation detail of the cproton module. I would guess there are similar reasons for perl and java as well, but I don't know. --Rafael
Re: inconsistent proton library names?
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 inconsistent for the former to state its Perl-ness in its name, and for the latter to state its Swig-ness. Thoughts? Phil On Fri, Jan 04, 2013 at 11:04:31AM -0500, Ted Ross 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 are dictated by the scripting language's extension mechanisms. That's true. The Ruby VM requires the name for a native extension library has to match the name of the extension, and also the initialization entry point in the library; i.e., in order to do a require 'qpid_proton' we need a file named qpid_proton.so that has an method named Init_qpid_proton inside. -- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/
Re: inconsistent proton library names?
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 libcproton.so. 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 cproton_perl because otherwise Cmake fails. That's because we already have a target named cproton and changing Perl to that will cause a name collision. And, anyway, the output of Cmake isn't used to distribution the Perl language bindings. Those are distributed as the perl.i file, Makefile.PL, various license and doc files, and the qpid::proton namespace classes. When that's installed, a proper library is generated for Perl to use. -- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ pgpWUHjFzADxW.pgp Description: PGP signature
Re: inconsistent proton library names?
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 be renamed to libcproton.so. 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? 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 buttercream frosting layer that wraps the raw C extension module. I would hope we'd have something similar for perl and Java so that these names shouldn't ever be visible to users. --Rafael
Re: inconsistent proton library names?
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 buttercream frosting layer that wraps the raw C extension module. I would hope we'd have something similar for perl and Java so that these names shouldn't ever be visible to users. Per does. It uses qpid::proton namespace for the Message and Messenger classes. -- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ pgp_tHqax8Gso.pgp Description: PGP signature
Re: inconsistent proton library names?
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: bindings/perl/libcproton_perl.so bindings/java/libproton-swig.so ... should both be renamed to libcproton.so. 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 cproton_perl because otherwise Cmake fails. That's because we already have a target named cproton and changing Perl to that will cause a name collision. And, anyway, the output of Cmake isn't used to distribution the Perl language bindings. Those are distributed as the perl.i file, Makefile.PL, various license and doc files, and the qpid::proton namespace classes. When that's installed, a proper library is generated for Perl to use. Hmm, this doesn't seem to quite be the case. The cmake build does in fact install the swig generated files, i.e. libcproton_perl.so, and cproton_perl.pm, however it does not install the qpid::proton namespace classes. --Rafael
Re: inconsistent proton library names?
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 instantiated by a java.util.ServiceLoader. The decision will therefore depend on your runtime classpath. Client code will not have a build time dependency on the Swig/JNI layer. [1] http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-j/proton-api/src/main/java/org/apache/qpid/proton/engine/Connection.java On 4 January 2013 20:40, Darryl L. Pierce dpie...@redhat.com wrote: 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 buttercream frosting layer that wraps the raw C extension module. I would hope we'd have something similar for perl and Java so that these names shouldn't ever be visible to users. Per does. It uses qpid::proton namespace for the Message and Messenger classes. -- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/
Re: inconsistent proton library names?
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 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 instantiated by a java.util.ServiceLoader. The decision will therefore depend on your runtime classpath. Client code will not have a build time dependency on the Swig/JNI layer. [1] http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-j/proton-api/src/main/java/org/apache/qpid/proton/engine/Connection.java On 4 January 2013 20:40, Darryl L. Pierce dpie...@redhat.com wrote: 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 buttercream frosting layer that wraps the raw C extension module. I would hope we'd have something similar for perl and Java so that these names shouldn't ever be visible to users. Per does. It uses qpid::proton namespace for the Message and Messenger classes. -- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/
Re: inconsistent proton library names?
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 nice when writing interoperability tests. Phil On Jan 4, 2013 9:16 PM, Rafael Schloming r...@alum.mit.edu wrote: 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.com wrote: 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 instantiated by a java.util.ServiceLoader. The decision will therefore depend on your runtime classpath. Client code will not have a build time dependency on the Swig/JNI layer. [1] http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-j/proton-api/src/main/java/org/apache/qpid/proton/engine/Connection.java On 4 January 2013 20:40, Darryl L. Pierce dpie...@redhat.com wrote: 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 buttercream frosting layer that wraps the raw C extension module. I would hope we'd have something similar for perl and Java so that these names shouldn't ever be visible to users. Per does. It uses qpid::proton namespace for the Message and Messenger classes. -- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/
