[jira] [Commented] (PROTON-573) proton-c: Messenger appears to have hard-coded address limits of 1024
[ https://issues.apache.org/jira/browse/PROTON-573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14010980#comment-14010980 ] Dominic Evans commented on PROTON-573: -- Thanks [~rhs] - have replaced our local patch with your reworked one. Changes tested and working. proton-c: Messenger appears to have hard-coded address limits of 1024 - Key: PROTON-573 URL: https://issues.apache.org/jira/browse/PROTON-573 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Dominic Evans Assignee: Rafael H. Schloming Attachments: 06_arbitrary_length_addresses_in_store.patch, 07_arbitrary_length_addresses_in_messenger.patch The AMQP 1.0 spec permits pretty much arbitrary length link names, but Messenger hard-codes some 1K limits in various places. -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: Help connecting with SSL
Just an update on the progress.. The 581 patch for Proton works and I now have publisher that publishes to the server via amqps. However we cannot see any messages arriving at the ServiceBus queue(s). In essence, the call to pn_messenger_put works, but when I call pn_messenger_recv, I get an error implying that there are no valid sources. TLS Ken Giusti wrote Hi, - Original Message - From: TheLoneStranger lt; mark.sheedy@ gt; To: proton@.apache Sent: Tuesday, May 27, 2014 11:41:10 AM Subject: Re: Help connecting with SSL Hi Ken, Thanks for the help so far. I have tried the msgr-send.c in the excample directory, and it gives the same error as before.. CONNECTION ERROR invalid credentials The underlying cause of this is a call to pn_ssl_domain_set_credentials which calls the pn_ssl_domain_set_credentials in the ssl_stub.c file. So, I suppose my next question is how do I switch to use the proper pn_ssl_domain_set_credentials, i.e. the one from the ssl/openssl.c file. Aha! Yes, I see the problem now - if you are calling ssl_stub.c, that means you haven't built against the OpenSSL library. Proton uses OpenSSL for its SSL implementation. When you configure your Proton build, it looks for the presence of the OpenSSL libraries on your system. If they are not present, it uses ssl_stub.c instead, which will not allow you to try to set up SSL connections (since the OpenSSL libraries are not present). What system are you trying to build your clients on? OpenSSL is not supported on Windows, btw, and Proton does not yet have support for SSL on windows - see Cliff's previous email on this topic: https://issues.apache.org/jira/browse/PROTON-581 Regards, TLS -- View this message in context: http://qpid.2158936.n2.nabble.com/Help-connecting-with-SSL-tp7608636p7608666.html Sent from the Apache Qpid Proton mailing list archive at Nabble.com. -- -K -- View this message in context: http://qpid.2158936.n2.nabble.com/Help-connecting-with-SSL-tp7608636p7608698.html Sent from the Apache Qpid Proton mailing list archive at Nabble.com.
Re: codec updates
On Tue, May 27, 2014 at 5:15 PM, Robbie Gemmell robbie.gemm...@gmail.comwrote:
I haven't had time to run any of this or look through it properly yet, but
after a very very quick scroll through...
- Should we not use LinkedHashMap instances, due to the ordering
restriction on equality checks for amqp maps?
Probably, although I should say that I didn't intend for POJOBuilder to
retain 100% fidelity of AMQP type information, but rather to transform the
data stream into something that is natural to process in Java. The idea
being that this gives you a high degree of convenience (as well as avoiding
overhead) most of the time when full fidelity shouldn't matter.
As a general note, the overall design is intended to make transformation
efficient and relatively easy, so it should be possible to go directly from
the input byte stream to the domain specific objects you want to work with
in your program without unnecessary intermediate representations. This also
means that there isn't one single canonical transformer, but multiple
transformers depending on what you want to do. For example an application
might use a POJO style transformer or even a domain specific transformer
for decoding and processing an application message, but a broker might use
a transformer that goes directly from input message bytes to output message
bytes (modulo updated ttl), or the protocol engine might use a transformer
that directly executes performatives.
- It looked like it only uses list32, array32, string32 for encoding...do
you envisage supporting the others?
Yes, however there is a time/space-on-the-wire trade-off here. One of the
reasons this codec is faster on encode than the existing codec is that it
doesn't attempt to compute the encoded size of a given value in advance. It
simply reserves the space on the wire and then goes and backfills it when
it is done encoding the value. This alone turns into something close to a
factor of two in speedup because computing the size has approximately the
same cost as performing the encoding. The trade-off of course is that it
doesn't know in advance what width to reserve for the size and count, so it
needs to assume the wider width. There may be some clever things we can do
here, e.g. there may be an inexpensive way to make a mostly accurate guess
and then shift stuff around if it turns out to be wrong, however those
kinds of things would require a more representative sample of data to work
with in order to validate.
Ultimately I suspect what is optimal for speed may never be optimal for
size, so the fallback here would be to simply provide two flavors of
implementation of the Encoder interface, one tailored for speed, and one
tailored for space-on-the-wire.
- Glancing at the example, this made me do a double take - is that an array
of string with a url in it, or somehow an array of url?
(I guess I need to look at what the code actually does with this :P)
enc.putArray(Type.STRING);
enc.putDescriptor();
enc.putSymbol(url);
enc.putString(http://one;);
enc.putString(http://two;);
enc.putString(http://three;);
enc.end();
This is actually an array of described strings where the descriptor is the
symbol url.
- For the maps, it feels a little weird adding the keys and values
independently, though I guess thats to let us away without additional
map-specific methods?
enc.putMap();
enc.putString(key);
enc.putString(value);
enc.putString(pi);
enc.putDouble(3.14159265359);
enc.end();
I'm not sure how map specific methods would work. I can't think of a way to
do it offhand that wouldn't result in a fairly ugly combinatorial explosion
of signatures. I think there are two key things about this aspect of the
design. First, the API deals in stuff that is presented in serial order, so
the implementation can simply directly encode values onto the wire when
they are presented and only needs to keep around minimal internal state.
Secondly, the API is designed to be composable, e.g. imagine you have some
DomainType that knows how to serialize itself. With this interface you can
do things like:
enc.putMap();
enc.putString(key);
domainType.encodeYourself(enc);
enc.putString(next-key);
enc.putString(next-value);
enc.end();
You can also do:
enc.putList();
...
domainType.encodeYourself(enc);
...
enc.end();
The general idea is to allow domain specific encoding pretty much the same
way that people write toString() methods, and so you need a given value to
render the same way regardless of whether it appears in a list or in a map
or even as a key in a map vs a value in a map.
I think this model becomes more natural if you think of this as an API for
expressing map/list literals rather than as an API for constructing
map/list objects, e.g.:
{ key: value, pi: 3.14159265359 } - enc.putMap();
enc.putString(key); enc.putString(value);
Re: Help connecting with SSL
On Wed, May 28, 2014 at 9:13 AM, TheLoneStranger mark.she...@edftrading.com wrote: Just an update on the progress.. The 581 patch for Proton works and I now have publisher that publishes to the server via amqps. However we cannot see any messages arriving at the ServiceBus queue(s). In essence, the call to pn_messenger_put works, but when I call pn_messenger_recv, I get an error implying that there are no valid sources. Can you post some sample code? The no valid sources error implies that you have not successfully subscribed to the queue, but it doesn't say anything about whether or not the message you published made it into the queue or not. I would suggest checking the queue size before/after publishing your messages so that you can isolate send issues from receive issues. --Rafael
[jira] [Updated] (PROTON-518) Add SASL hostname getter/setter
[ https://issues.apache.org/jira/browse/PROTON-518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming updated PROTON-518: --- Fix Version/s: (was: 0.7) Add SASL hostname getter/setter --- Key: PROTON-518 URL: https://issues.apache.org/jira/browse/PROTON-518 Project: Qpid Proton Issue Type: Improvement Components: proton-j Reporter: Hiram Chirino -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (PROTON-565) Modify the Messenger to use the Collector API.
[ https://issues.apache.org/jira/browse/PROTON-565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming updated PROTON-565: --- Fix Version/s: (was: 0.7) 0.8 Modify the Messenger to use the Collector API. -- Key: PROTON-565 URL: https://issues.apache.org/jira/browse/PROTON-565 Project: Qpid Proton Issue Type: Improvement Components: proton-j Reporter: Rajith Attapattu Assignee: Rajith Attapattu Fix For: 0.8 Attachments: PROTON-565.part1.patch Modify the Messenger to use the Collector API instead of querying the for state changes. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (PROTON-521) Replace proton-project with proton in maven related build files
[ https://issues.apache.org/jira/browse/PROTON-521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming resolved PROTON-521. Resolution: Won't Fix Fix Version/s: (was: 0.7) Replace proton-project with proton in maven related build files --- Key: PROTON-521 URL: https://issues.apache.org/jira/browse/PROTON-521 Project: Qpid Proton Issue Type: Bug Components: proton-j Affects Versions: 0.6 Reporter: Irina Boverman Priority: Trivial Attachments: replace-proton-project.txt This change makes it easier to build downstream products. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (PROTON-512) Possibility to set idle timeout for messenger
[ https://issues.apache.org/jira/browse/PROTON-512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming updated PROTON-512: --- Fix Version/s: (was: 0.7) 0.8 Possibility to set idle timeout for messenger - Key: PROTON-512 URL: https://issues.apache.org/jira/browse/PROTON-512 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.6 Reporter: Tomas Soltys Labels: features, patch Fix For: 0.8 Attachments: messenger.c.patch, messenger.h.patch I would like to specify an idle timeout for a messenger which would be then used for all created connections. I see that there is an interface for pn_transport_t which is allowing it but it is not accessible from outside. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (PROTON-516) [proton-c] Dispatcher frame buffer set to peer's max frame size.
[ https://issues.apache.org/jira/browse/PROTON-516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming updated PROTON-516: --- Fix Version/s: (was: 0.7) 0.8 [proton-c] Dispatcher frame buffer set to peer's max frame size. Key: PROTON-516 URL: https://issues.apache.org/jira/browse/PROTON-516 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.6 Reporter: Ken Giusti Assignee: Ken Giusti Fix For: 0.8 The size of the output frame buffer used by the Transport is set unconditionally to the max frame size advertised by the peer: In transport.c::int pn_do_open(pn_dispatcher_t *disp): pn_buffer_ensure( disp-frame, disp-remote_max_frame ); This can potentially exhaust memory on small memory systems (eg, embedded devices). Instead, the output frame buffer should grow as needed based on the size of the payloads generated, limited by the remote_max_frame value. And, of course, pn_buffer_ensure + caller should handle realloc failures instead of ignoring them. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (PROTON-515) Port to OpenVMS
[ https://issues.apache.org/jira/browse/PROTON-515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming updated PROTON-515: --- Fix Version/s: (was: 0.7) 0.8 Port to OpenVMS --- Key: PROTON-515 URL: https://issues.apache.org/jira/browse/PROTON-515 Project: Qpid Proton Issue Type: Improvement Components: proton-c Affects Versions: 0.6 Environment: OpenVMS Reporter: Tomas Soltys Labels: OpenVMS, patch Fix For: 0.8 Attachments: codec.c.patch, driver.c.patch, message.c.patch There is a need for proton-c port to OpenVMS platform. To make proton-c functional on OpenVMS few changes in the source code are required. Here is list of files I have identified which require some attention: proton-c/src/platform_fmt.h proton-c/src/posix/driver.c proton-c/src/object/object.c proton-c/src/codec/codec.c -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (PROTON-516) [proton-c] Dispatcher frame buffer set to peer's max frame size.
[ https://issues.apache.org/jira/browse/PROTON-516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming reassigned PROTON-516: -- Assignee: Rafael H. Schloming (was: Ken Giusti) [proton-c] Dispatcher frame buffer set to peer's max frame size. Key: PROTON-516 URL: https://issues.apache.org/jira/browse/PROTON-516 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.6 Reporter: Ken Giusti Assignee: Rafael H. Schloming Fix For: 0.8 The size of the output frame buffer used by the Transport is set unconditionally to the max frame size advertised by the peer: In transport.c::int pn_do_open(pn_dispatcher_t *disp): pn_buffer_ensure( disp-frame, disp-remote_max_frame ); This can potentially exhaust memory on small memory systems (eg, embedded devices). Instead, the output frame buffer should grow as needed based on the size of the payloads generated, limited by the remote_max_frame value. And, of course, pn_buffer_ensure + caller should handle realloc failures instead of ignoring them. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (PROTON-516) [proton-c] Dispatcher frame buffer set to peer's max frame size.
[ https://issues.apache.org/jira/browse/PROTON-516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming updated PROTON-516: --- Assignee: Andrew Stitcher (was: Rafael H. Schloming) [proton-c] Dispatcher frame buffer set to peer's max frame size. Key: PROTON-516 URL: https://issues.apache.org/jira/browse/PROTON-516 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.6 Reporter: Ken Giusti Assignee: Andrew Stitcher Fix For: 0.8 The size of the output frame buffer used by the Transport is set unconditionally to the max frame size advertised by the peer: In transport.c::int pn_do_open(pn_dispatcher_t *disp): pn_buffer_ensure( disp-frame, disp-remote_max_frame ); This can potentially exhaust memory on small memory systems (eg, embedded devices). Instead, the output frame buffer should grow as needed based on the size of the payloads generated, limited by the remote_max_frame value. And, of course, pn_buffer_ensure + caller should handle realloc failures instead of ignoring them. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (PROTON-474) Incorrect mapping of TTL to JMSExpiration in JMS InboundTransformer
[ https://issues.apache.org/jira/browse/PROTON-474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming updated PROTON-474: --- Fix Version/s: (was: 0.7) 0.8 Incorrect mapping of TTL to JMSExpiration in JMS InboundTransformer --- Key: PROTON-474 URL: https://issues.apache.org/jira/browse/PROTON-474 Project: Qpid Proton Issue Type: Bug Components: proton-j Affects Versions: 0.5 Reporter: Timothy Bish Fix For: 0.8 Attachments: JMSExpiration-patch.txt, PROTON-474-v2.patch The inbound message transformation of AMQP message to JMS message incorrectly sets the JMSExpiration to message TTL which is defined in milliseconds while the JMSExpiration value is a sum of the Message Timestamp and the producers TTL. The transformation should probably map the message creation time + the TTL to the setJMSExpiration method. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (PROTON-509) Proton build fails on OS X 10.9
[ https://issues.apache.org/jira/browse/PROTON-509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming updated PROTON-509: --- Fix Version/s: (was: 0.7) 0.8 Proton build fails on OS X 10.9 --- Key: PROTON-509 URL: https://issues.apache.org/jira/browse/PROTON-509 Project: Qpid Proton Issue Type: Bug Components: proton-c Reporter: Hiram Chirino Fix For: 0.8 Build failure posted at: https://gist.github.com/chirino/8823091 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (PROTON-476) Support a user-context for SASL and SSL objects.
[ https://issues.apache.org/jira/browse/PROTON-476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming updated PROTON-476: --- Fix Version/s: (was: 0.7) 0.8 Support a user-context for SASL and SSL objects. Key: PROTON-476 URL: https://issues.apache.org/jira/browse/PROTON-476 Project: Qpid Proton Issue Type: New Feature Components: proton-c Affects Versions: 0.5 Reporter: Ken Giusti Fix For: 0.8 For consistency and convenience, I'd like to add an API that would allow an application-defined context be associated with the pn_sasl_t, pn_ssl_domain_t, and pn_ssl_t objects. This api would follow the convention used by other proton classes (eg, pn_connection_get_context(), pn_connection_set_context()). ex: void *pn_sasl_get_context(pn_sasl_t); void pn_sasl_set_context(pn_sasl_t *, void *context); -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (PROTON-462) Documentation: Add doxygen overview file for Proton C API
[ https://issues.apache.org/jira/browse/PROTON-462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming updated PROTON-462: --- Fix Version/s: (was: 0.7) 0.8 Documentation: Add doxygen overview file for Proton C API - Key: PROTON-462 URL: https://issues.apache.org/jira/browse/PROTON-462 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.5 Reporter: Ken Giusti Assignee: Rafael H. Schloming Fix For: 0.8 If possible, have the web page link to the *public header files* as the start page - that's were the meat of the API documentation exists. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (PROTON-439) Support for dynamic reply-to address in Messenger
[ https://issues.apache.org/jira/browse/PROTON-439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming resolved PROTON-439. Resolution: Fixed Support for dynamic reply-to address in Messenger - Key: PROTON-439 URL: https://issues.apache.org/jira/browse/PROTON-439 Project: Qpid Proton Issue Type: New Feature Components: proton-c Affects Versions: 0.5 Reporter: Ted Ross Assignee: Rafael H. Schloming Fix For: 0.7 Messenger has no support for creating dynamic receivers for reply-to addresses. Please refer to the following email thread for prior discussion on the topic. http://qpid.2158936.n2.nabble.com/Proton-Messenger-and-the-Request-Response-pattern-tp7586653.html -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (PROTON-453) OpenSSL libraries are not Valgrind clean
[ https://issues.apache.org/jira/browse/PROTON-453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti resolved PROTON-453. --- Resolution: Fixed Added a valgrind suppression file. Will have to be kept up-to-date as newer versions of OpenSSL may introduce additional Valgrind errors. OpenSSL libraries are not Valgrind clean Key: PROTON-453 URL: https://issues.apache.org/jira/browse/PROTON-453 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.5 Reporter: Ken Giusti Assignee: Ken Giusti Priority: Trivial Fix For: 0.7 OpenSSL will trigger errors under Valgrind. This is expected, as OpenSSL uses uninitialized memory to increase its randomness. http://www.openssl.org/support/faq.html#PROG14 These errors can be suppressed by using a Valgrind suppression file. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (PROTON-287) Fix Qpid Proton-C build with MinGW on Fedora
[ https://issues.apache.org/jira/browse/PROTON-287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming updated PROTON-287: --- Fix Version/s: (was: 0.7) 0.8 Fix Qpid Proton-C build with MinGW on Fedora Key: PROTON-287 URL: https://issues.apache.org/jira/browse/PROTON-287 Project: Qpid Proton Issue Type: Improvement Components: proton-c Affects Versions: 0.4 Environment: mingw32-gcc-4.7.2-7.fc18.x86_64 Reporter: Robin Lee Assignee: Cliff Jansen Labels: build, patch Fix For: 0.8 This is my first submit on ASF JIRA. Fix Qpid Proton-C build with MinGW on Fedora. Patches are provided: Patch 1: http://cheeselee.fedorapeople.org/qpid-proton_trunk_MinGW_STDIO.diff Description: %z format specifier is not provided by MSVCRT, use MinGW version of *printf to get it. Otherwise build failed with: proton-c/src/codec/codec.c:1951:3: error: unknown conversion type character 'z' in format [-Werror=format] Patch 2: http://cheeselee.fedorapeople.org/qpid-proton_trunk_small_cases.diff Description: Libraries and header files should be written in small cases, otherwise build failed in cross build environment of Unix-like platforms: proton-c/src/windows/driver.c:44:22: fatal error: Ws2tcpip.h: No such file or directory Patch 3: http://cheeselee.fedorapeople.org/qpid-proton_trunk_pn_connector_t.diff Description: Change pn_connector_t::fd to type of pn_socket_t. Otherwise, since on Windows platform, pn_socket_t (typedef of SOCKET) is unsigned, build failed with: proton-c/src/windows/driver.c:785:11: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare] Patch 4: http://cheeselee.fedorapeople.org/qpid-proton_trunk_unimplemented_functions.diff Description: Commented unimplemented functions. Otherwise build failed with proton-c/src/windows/driver.c:416:13: error: 'pn_connector_write' declared 'static' but never defined [-Werror=unused-function] Patch 5: http://cheeselee.fedorapeople.org/qpid-proton_trunk_wincompat-getopt.diff Description: 1. ID is not used, build failed with ../wincompat/internal/getopt.c:43:20: error: 'ID' defined but not used [-Werror=unused-variable] 2. Corrected getopt signiture, otherwise build failed with proton-c/src/../wincompat/internal/getopt.c:97:5: note: expected 'char *' but argument is of type 'const char *' 3. wincompat/getopt.h #include wincompat/internal/getopt.c directly, so #include wincompat/getopt.h in .c files instead of .h, otherwise build failed with multiple definitions. Patch 6: http://cheeselee.fedorapeople.org/qpid-proton_trunk_WIN32_macro.diff Description: WIN32 macro is not defined with -std=c99 but defined with -std=gnu99. Use _WIN32 macro in all places. Built on Fedora and examples of recv and send are tested on Windows 7. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (PROTON-587) Proton 0.7 fails to compile with Visual Studio 2008
Chuck Rolke created PROTON-587:
--
Summary: Proton 0.7 fails to compile with Visual Studio 2008
Key: PROTON-587
URL: https://issues.apache.org/jira/browse/PROTON-587
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: 0.7
Environment: Visual Studio 2008 x86 (32-bit) debug or relwithdebinfo.
Note: VS2008 x64 (64-bit) works fine; VS2010 x86,x64 work fine.
Reporter: Chuck Rolke
Project recv.c fails to compile with size_t undefined.
{noformat}
6-- Build started: Project: recv, Configuration: Debug Win32 --
6Compiling...
6recv.c
6P:\qpid-proton-0.7\proton-c\include\proton/types.h(60) : error C2016: C
requires that a struct or union has at least one member
6P:\qpid-proton-0.7\proton-c\include\proton/types.h(60) : error C2061: syntax
error : identifier 'size_t'
6P:\qpid-proton-0.7\proton-c\include\proton/types.h(62) : error C2059: syntax
error : '}'
...
{noformat}
The issue if fixed easy enough with the inclusion of stddef.h or stdlib.h in
types.h
{noformat}
diff --git a/proton-c/include/proton/types.h b/proton-c/include/proton/types.h
index 4182f25..d26d6a2 100644
--- a/proton-c/include/proton/types.h
+++ b/proton-c/include/proton/types.h
@@ -23,6 +23,7 @@
*/
#include proton/import_export.h
+#include stddef.h
#include sys/types.h
#include proton/type_compat.h
{noformat}
Apologies for not catching this sooner but I've been using VS2010 almost
exclusively of late. The fix looks harmless enough but I'm wondering if anyone
has an reason to select stddef over stdlib or if there's a better place to have
the #include.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (PROTON-587) Proton 0.7 fails to compile with Visual Studio 2008
[
https://issues.apache.org/jira/browse/PROTON-587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rafael H. Schloming updated PROTON-587:
---
Assignee: Andrew Stitcher
Proton 0.7 fails to compile with Visual Studio 2008
---
Key: PROTON-587
URL: https://issues.apache.org/jira/browse/PROTON-587
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: 0.7
Environment: Visual Studio 2008 x86 (32-bit) debug or relwithdebinfo.
Note: VS2008 x64 (64-bit) works fine; VS2010 x86,x64 work fine.
Reporter: Chuck Rolke
Assignee: Andrew Stitcher
Project recv.c fails to compile with size_t undefined.
{noformat}
6-- Build started: Project: recv, Configuration: Debug Win32 --
6Compiling...
6recv.c
6P:\qpid-proton-0.7\proton-c\include\proton/types.h(60) : error C2016: C
requires that a struct or union has at least one member
6P:\qpid-proton-0.7\proton-c\include\proton/types.h(60) : error C2061:
syntax error : identifier 'size_t'
6P:\qpid-proton-0.7\proton-c\include\proton/types.h(62) : error C2059:
syntax error : '}'
...
{noformat}
The issue if fixed easy enough with the inclusion of stddef.h or stdlib.h in
types.h
{noformat}
diff --git a/proton-c/include/proton/types.h b/proton-c/include/proton/types.h
index 4182f25..d26d6a2 100644
--- a/proton-c/include/proton/types.h
+++ b/proton-c/include/proton/types.h
@@ -23,6 +23,7 @@
*/
#include proton/import_export.h
+#include stddef.h
#include sys/types.h
#include proton/type_compat.h
{noformat}
Apologies for not catching this sooner but I've been using VS2010 almost
exclusively of late. The fix looks harmless enough but I'm wondering if
anyone has an reason to select stddef over stdlib or if there's a better
place to have the #include.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (PROTON-587) Proton 0.7 fails to compile with Visual Studio 2008
[
https://issues.apache.org/jira/browse/PROTON-587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14011348#comment-14011348
]
Andrew Stitcher commented on PROTON-587:
#include stddef.h
seems to be the correct way to get the definition. This change looks fine.
Proton 0.7 fails to compile with Visual Studio 2008
---
Key: PROTON-587
URL: https://issues.apache.org/jira/browse/PROTON-587
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: 0.7
Environment: Visual Studio 2008 x86 (32-bit) debug or relwithdebinfo.
Note: VS2008 x64 (64-bit) works fine; VS2010 x86,x64 work fine.
Reporter: Chuck Rolke
Assignee: Andrew Stitcher
Project recv.c fails to compile with size_t undefined.
{noformat}
6-- Build started: Project: recv, Configuration: Debug Win32 --
6Compiling...
6recv.c
6P:\qpid-proton-0.7\proton-c\include\proton/types.h(60) : error C2016: C
requires that a struct or union has at least one member
6P:\qpid-proton-0.7\proton-c\include\proton/types.h(60) : error C2061:
syntax error : identifier 'size_t'
6P:\qpid-proton-0.7\proton-c\include\proton/types.h(62) : error C2059:
syntax error : '}'
...
{noformat}
The issue if fixed easy enough with the inclusion of stddef.h or stdlib.h in
types.h
{noformat}
diff --git a/proton-c/include/proton/types.h b/proton-c/include/proton/types.h
index 4182f25..d26d6a2 100644
--- a/proton-c/include/proton/types.h
+++ b/proton-c/include/proton/types.h
@@ -23,6 +23,7 @@
*/
#include proton/import_export.h
+#include stddef.h
#include sys/types.h
#include proton/type_compat.h
{noformat}
Apologies for not catching this sooner but I've been using VS2010 almost
exclusively of late. The fix looks harmless enough but I'm wondering if
anyone has an reason to select stddef over stdlib or if there's a better
place to have the #include.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (PROTON-587) Proton 0.7 fails to compile with Visual Studio 2008
[
https://issues.apache.org/jira/browse/PROTON-587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14011375#comment-14011375
]
ASF subversion and git services commented on PROTON-587:
Commit 1598084 from c...@apache.org in branch 'proton/trunk'
[ https://svn.apache.org/r1598084 ]
PROTON-587: Fails to compile Visual Studio 2008
This fix provides a definition for size_t in that compiler suite.
Proton 0.7 fails to compile with Visual Studio 2008
---
Key: PROTON-587
URL: https://issues.apache.org/jira/browse/PROTON-587
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: 0.7
Environment: Visual Studio 2008 x86 (32-bit) debug or relwithdebinfo.
Note: VS2008 x64 (64-bit) works fine; VS2010 x86,x64 work fine.
Reporter: Chuck Rolke
Assignee: Andrew Stitcher
Project recv.c fails to compile with size_t undefined.
{noformat}
6-- Build started: Project: recv, Configuration: Debug Win32 --
6Compiling...
6recv.c
6P:\qpid-proton-0.7\proton-c\include\proton/types.h(60) : error C2016: C
requires that a struct or union has at least one member
6P:\qpid-proton-0.7\proton-c\include\proton/types.h(60) : error C2061:
syntax error : identifier 'size_t'
6P:\qpid-proton-0.7\proton-c\include\proton/types.h(62) : error C2059:
syntax error : '}'
...
{noformat}
The issue if fixed easy enough with the inclusion of stddef.h or stdlib.h in
types.h
{noformat}
diff --git a/proton-c/include/proton/types.h b/proton-c/include/proton/types.h
index 4182f25..d26d6a2 100644
--- a/proton-c/include/proton/types.h
+++ b/proton-c/include/proton/types.h
@@ -23,6 +23,7 @@
*/
#include proton/import_export.h
+#include stddef.h
#include sys/types.h
#include proton/type_compat.h
{noformat}
Apologies for not catching this sooner but I've been using VS2010 almost
exclusively of late. The fix looks harmless enough but I'm wondering if
anyone has an reason to select stddef over stdlib or if there's a better
place to have the #include.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (PROTON-587) Proton 0.7 fails to compile with Visual Studio 2008
[
https://issues.apache.org/jira/browse/PROTON-587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chuck Rolke resolved PROTON-587.
Resolution: Fixed
Fix Version/s: 0.8
Proton 0.7 fails to compile with Visual Studio 2008
---
Key: PROTON-587
URL: https://issues.apache.org/jira/browse/PROTON-587
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: 0.7
Environment: Visual Studio 2008 x86 (32-bit) debug or relwithdebinfo.
Note: VS2008 x64 (64-bit) works fine; VS2010 x86,x64 work fine.
Reporter: Chuck Rolke
Assignee: Andrew Stitcher
Fix For: 0.8
Project recv.c fails to compile with size_t undefined.
{noformat}
6-- Build started: Project: recv, Configuration: Debug Win32 --
6Compiling...
6recv.c
6P:\qpid-proton-0.7\proton-c\include\proton/types.h(60) : error C2016: C
requires that a struct or union has at least one member
6P:\qpid-proton-0.7\proton-c\include\proton/types.h(60) : error C2061:
syntax error : identifier 'size_t'
6P:\qpid-proton-0.7\proton-c\include\proton/types.h(62) : error C2059:
syntax error : '}'
...
{noformat}
The issue if fixed easy enough with the inclusion of stddef.h or stdlib.h in
types.h
{noformat}
diff --git a/proton-c/include/proton/types.h b/proton-c/include/proton/types.h
index 4182f25..d26d6a2 100644
--- a/proton-c/include/proton/types.h
+++ b/proton-c/include/proton/types.h
@@ -23,6 +23,7 @@
*/
#include proton/import_export.h
+#include stddef.h
#include sys/types.h
#include proton/type_compat.h
{noformat}
Apologies for not catching this sooner but I've been using VS2010 almost
exclusively of late. The fix looks harmless enough but I'm wondering if
anyone has an reason to select stddef over stdlib or if there's a better
place to have the #include.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
Proton-c on android
I am trying to get proton-c to run on android. Does anybody have any advice or experience on the matter that I can get in contact with?
Re: Proton-c on android
Wouldn't Proton-j be a better fit? On May 28, 2014, at 8:45 PM, Jimmy Campbell t-jic...@microsoft.com wrote: I am trying to get proton-c to run on android. Does anybody have any advice or experience on the matter that I can get in contact with?
