[jira] [Created] (PROTON-65) Provide a AMQP 1.0 Message to JMS Message mapping logic/module
Hiram Chirino created PROTON-65: --- Summary: Provide a AMQP 1.0 Message to JMS Message mapping logic/module Key: PROTON-65 URL: https://issues.apache.org/jira/browse/PROTON-65 Project: Qpid Proton Issue Type: New Feature Components: proton-j Reporter: Hiram Chirino Having a easy/consistent way to transform a JMS message to an AMQP message and back would be super handy. Having that logic live in proton would help make that mapping more standardized as different client and sever implementations can just re-use the logic. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (PROTON-65) Provide a AMQP 1.0 Message to JMS Message mapping logic/module
[ https://issues.apache.org/jira/browse/PROTON-65?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hiram Chirino updated PROTON-65: Attachment: PROTON-65.patch Attaching patch that implements the jms mapping. It adds a new proton-jms modules. This depends on the PROTON-35 patch being applied first. Provide a AMQP 1.0 Message to JMS Message mapping logic/module -- Key: PROTON-65 URL: https://issues.apache.org/jira/browse/PROTON-65 Project: Qpid Proton Issue Type: New Feature Components: proton-j Reporter: Hiram Chirino Attachments: PROTON-65.patch Having a easy/consistent way to transform a JMS message to an AMQP message and back would be super handy. Having that logic live in proton would help make that mapping more standardized as different client and sever implementations can just re-use the logic. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PROTON-57) Proton porting problems between current codebase and Visual Studio 2010 toolset
[ https://issues.apache.org/jira/browse/PROTON-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13472436#comment-13472436 ] Rafael H. Schloming commented on PROTON-57: --- Thanks for generating the list, I think this is quite manageable. Here's my take on what we should do in each case: proton.c: This is a very outdated example that should probably be moved and/or renamed and/or updated/replaced or possibly just deleted. The use of VLAs here is just for creating message data, if this is done through the message API then we should be able to eliminate the VLAs whilst simultaneously making the example a tad more useful. codec.c: pn_print_atoms(...) This is only used for debug printing, so I think it's entirely unnecessary to allow for an arbitrarily large array. We can just use a fixed maximum, so long as we handle the overflow case so that the string is a) properly terminated, and b) indicates to the user that the debug output has been truncated in some way. pn_data_encode/decode(...) For these we should add a dedicated array to pn_data_t and grow the array as needed. messenger.c: All of these are simply creating scratch buffers for string parsing and manipulation of addresses. I believe it would be reasonable to either A) impose a fixed maximum length on addresses, or B) add a dedicated scratch buffer to pn_messenger_t to hold the address for parsing. sasl.c: I'll volunteer to eliminate this one. (It's easier to do than to describe.) ;-) pn_fprint_data(...): Again this is only for debug output, so having a fixed maximum should be fine as long as we make it obvious that the displayed output is truncated. Proton porting problems between current codebase and Visual Studio 2010 toolset --- Key: PROTON-57 URL: https://issues.apache.org/jira/browse/PROTON-57 Project: Qpid Proton Issue Type: Improvement Components: proton-c Environment: Windows using Visual Studio 2010 Reporter: Mary hinton Labels: build This thread will be used to discuss the porting problems encountered using Visual Studio 2010 Here’s the first one to discuss: 1. Visual Studio doesn’t support variable length arrays. a. Currently using malloc()/realloc() in my port just to get it to compile and be able to report memory allocation errors. This is not what I want to submit to the proton group for memory allocation. b. Cliff had a good method that included setting up macros and replace the VLAs with alloca() in the Windows version, but it could still cause problems when the stack overflowed. VLAs can also run out of stack space. c. _malloca() should be a better way than _alloca() on Visual Studio. Any messages under 1K would be allocated out of the stack. Over 1K will use heap. If the average messages are under 1K, this may be the most efficient way in Visual Studio. _malloca() also has new security enhancements. 1. Using _malloca() in the Windows version and VLA in Linux would require two macros. The major difference for the Linux version would be to use the new macro for VLA and to include the new free macro even though there is nothing to free using VLA. In Visual Studio, _freea(buf) will not free anything if it is allocating off the stack. Linux can continue to use VLAs. #ifdef C99 #define PN_VLA(TYPE, buf, size) TYPE buf[size] #define PN_VLA_FREE #else #define PN_VLA(TYPE, buf, size) TYPE *buf = (TYPE*) _malloca(size) #define PN_VLA_FREE(buf) _freea(buf) #endif d. If the average size messages to allocate out of the stack needs to be increased for performance reasons, we can set up a new memory model. The 1K is not adjustable for _malloca(). We can set up new macros along the lines of Microsoft’s suggestion below. “I would suggest something similar to what ATL does. Use alloca for small (where you define what that is) sizes and use heap allocation for larger ones. You can wrap the logic inside of a class or macros. To work around the fact that alloca isn't cleaned up at block scope, rewrite the block into functions or use lambdas. (I think alloca works inside of lambdas.)” -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PROTON-65) Provide a AMQP 1.0 Message to JMS Message mapping logic/module
[ https://issues.apache.org/jira/browse/PROTON-65?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13472449#comment-13472449 ] Rajith Attapattu commented on PROTON-65: Hiram, One of the goals of proton is to be as as dependency free as possible, so it can be used in as many environments as possible. From that pov I don't think this is a good idea at all. For example, having the jms library as a dependency will be a big issue in using proton-j in Android (or similar environments). On the other hand if we can make this as a separate optional jar (maybe thats what you are doing in this patch, and I haven't messed with maven for ages) then that maybe acceptable. But still I'm not too comfortable with the idea. I'm not too sure if proton is the place to do so. I would like to see comments from other interested parties about this. Regards, Rajith Provide a AMQP 1.0 Message to JMS Message mapping logic/module -- Key: PROTON-65 URL: https://issues.apache.org/jira/browse/PROTON-65 Project: Qpid Proton Issue Type: New Feature Components: proton-j Reporter: Hiram Chirino Attachments: PROTON-65.patch Having a easy/consistent way to transform a JMS message to an AMQP message and back would be super handy. Having that logic live in proton would help make that mapping more standardized as different client and sever implementations can just re-use the logic. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PROTON-65) Provide a AMQP 1.0 Message to JMS Message mapping logic/module
[ https://issues.apache.org/jira/browse/PROTON-65?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13472451#comment-13472451 ] Hiram Chirino commented on PROTON-65: - Hi Rajith, The way the patch is setup, the logic creates a new proton-jms module so that JMS is not added as a dependency to the proton-j module. Please try out the patch and let me know what you think. Provide a AMQP 1.0 Message to JMS Message mapping logic/module -- Key: PROTON-65 URL: https://issues.apache.org/jira/browse/PROTON-65 Project: Qpid Proton Issue Type: New Feature Components: proton-j Reporter: Hiram Chirino Attachments: PROTON-65.patch Having a easy/consistent way to transform a JMS message to an AMQP message and back would be super handy. Having that logic live in proton would help make that mapping more standardized as different client and sever implementations can just re-use the logic. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PROTON-65) Provide a AMQP 1.0 Message to JMS Message mapping logic/module
[ https://issues.apache.org/jira/browse/PROTON-65?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13472540#comment-13472540 ] Rajith Attapattu commented on PROTON-65: Hiram, First of all, thx for confirming that it's indeed a separate jar. I figured it was the case, but wasn't too sure given that I haven't messed with mvn for long. I certainly see the value of having a mapping btw the AMQP message --- JMS Message and make it available for other folks to use it. But I'm not sure if proton is the right place to have it. Now to be fair to you, this is a discussion that goes beyond this particular issue. We have to make a clear statement about what proton is and what proton is not. Based on the discussions we had so far about the goals of proton, this doesn't seem to fit in well. IMO this is something that is best housed at Qpid (or even ActiveMQ for the time being). Again this is only my opinion. I would talk to other folks as well to see what they think about this. Regards, Rajith Provide a AMQP 1.0 Message to JMS Message mapping logic/module -- Key: PROTON-65 URL: https://issues.apache.org/jira/browse/PROTON-65 Project: Qpid Proton Issue Type: New Feature Components: proton-j Reporter: Hiram Chirino Attachments: PROTON-65.patch Having a easy/consistent way to transform a JMS message to an AMQP message and back would be super handy. Having that logic live in proton would help make that mapping more standardized as different client and sever implementations can just re-use the logic. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PROTON-65) Provide a AMQP 1.0 Message to JMS Message mapping logic/module
[ https://issues.apache.org/jira/browse/PROTON-65?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13472561#comment-13472561 ] Hiram Chirino commented on PROTON-65: - If it's not at proton, your encouraging proton users to implement it themselves in potentially incompatible ways. IMHO I think that would be very bad for folks Adopting AMQP and JMS. Provide a AMQP 1.0 Message to JMS Message mapping logic/module -- Key: PROTON-65 URL: https://issues.apache.org/jira/browse/PROTON-65 Project: Qpid Proton Issue Type: New Feature Components: proton-j Reporter: Hiram Chirino Attachments: PROTON-65.patch Having a easy/consistent way to transform a JMS message to an AMQP message and back would be super handy. Having that logic live in proton would help make that mapping more standardized as different client and sever implementations can just re-use the logic. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PROTON-65) Provide a AMQP 1.0 Message to JMS Message mapping logic/module
[ https://issues.apache.org/jira/browse/PROTON-65?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13472673#comment-13472673 ] Rob Godfrey commented on PROTON-65: --- I think it's more of a module/scoping question. I completely agree that we should have a JMS - Message adapter, hosted within Apache Qpid. The question is really about the scope of Proton as a sub-component of Qpid I think. One thing that a lot of us a very keen to ensure is that Proton is seen as a whole not as a whole load of independent language specific modules (since treating each language independently has caused us many issues in the past). Provide a AMQP 1.0 Message to JMS Message mapping logic/module -- Key: PROTON-65 URL: https://issues.apache.org/jira/browse/PROTON-65 Project: Qpid Proton Issue Type: New Feature Components: proton-j Reporter: Hiram Chirino Attachments: PROTON-65.patch Having a easy/consistent way to transform a JMS message to an AMQP message and back would be super handy. Having that logic live in proton would help make that mapping more standardized as different client and sever implementations can just re-use the logic. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (PROTON-64) SSL should support non-authenticated ciphers.
[ https://issues.apache.org/jira/browse/PROTON-64?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti resolved PROTON-64. -- Resolution: Fixed See http://svn.apache.org/viewvc?view=revisionrevision=1396381 SSL should support non-authenticated ciphers. - Key: PROTON-64 URL: https://issues.apache.org/jira/browse/PROTON-64 Project: Qpid Proton Issue Type: New Feature Components: proton-c Reporter: Ken Giusti Assignee: Ken Giusti Priority: Minor Current SSL implementation requires that the server be configured with a self-identifying certificate. The SSL implementation library (OpenSSL) does provide non-authenticating ciphers that do not require a certificate. This feature would allow use of said ciphers. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (PROTON-66) Driver implementation for proton-j
Rajith Attapattu created PROTON-66: -- Summary: Driver implementation for proton-j Key: PROTON-66 URL: https://issues.apache.org/jira/browse/PROTON-66 Project: Qpid Proton Issue Type: New Feature Reporter: Rajith Attapattu Provide an implementation for the Driver API. This consists of 3 interfaces. Connector, Listener and Driver. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
