You are viewing a plain text version of this content. The canonical link for it is here.
Posted to proton@qpid.apache.org by Phil Harvey <ph...@philharveyonline.com> on 2013/01/04 16:47:21 UTC
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?
Posted by Rafael Schloming <rh...@alum.mit.edu>.
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?
Posted by Phil Harvey <ph...@philharveyonline.com>.
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 <ro...@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 <ph...@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" <rh...@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 <phil@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 <dp...@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?
Posted by Rob Godfrey <ro...@gmail.com>.
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 <ph...@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" <rh...@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 <phil@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 <dp...@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?
Posted by Phil Harvey <ph...@philharveyonline.com>.
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" <rh...@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 <phil@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 <dp...@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?
Posted by Rafael Schloming <rh...@alum.mit.edu>.
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 <ph...@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 <dp...@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?
Posted by Phil Harvey <ph...@philharveyonline.com>.
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 <dp...@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?
Posted by "Darryl L. Pierce" <dp...@redhat.com>.
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?
Posted by Rafael Schloming <rh...@alum.mit.edu>.
On Fri, Jan 4, 2013 at 2:58 PM, Phil Harvey <ph...@philharveyonline.com>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?
>
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?
Posted by "Darryl L. Pierce" <dp...@redhat.com>.
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/
Re: inconsistent proton library names?
Posted by Rafael Schloming <rh...@alum.mit.edu>.
On Fri, Jan 4, 2013 at 3:15 PM, Darryl L. Pierce <dp...@redhat.com> wrote:
> On Fri, Jan 04, 2013 at 07:58:10PM +0000, 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?
Posted by "Darryl L. Pierce" <dp...@redhat.com>.
On Fri, Jan 04, 2013 at 07:58:10PM +0000, 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/
Re: inconsistent proton library names?
Posted by Phil Harvey <ph...@philharveyonline.com>.
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?
Posted by "Darryl L. Pierce" <dp...@redhat.com>.
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?
Posted by Ted Ross <tr...@redhat.com>.
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
>