[jira] [Closed] (PROTON-426) [Messenger] messenger has no ability to dynamically create queues/topics on qpidd

2013-10-25 Thread Ken Giusti (JIRA)

 [ 
https://issues.apache.org/jira/browse/PROTON-426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ken Giusti closed PROTON-426.
-


See QPID-5251

 [Messenger] messenger has no ability to dynamically create queues/topics on 
 qpidd
 -

 Key: PROTON-426
 URL: https://issues.apache.org/jira/browse/PROTON-426
 Project: Qpid Proton
  Issue Type: New Feature
  Components: proton-c
Affects Versions: 0.5
Reporter: Ken Giusti
 Fix For: 0.6


 The current QPID client addressing syntax provides a way to create and delete 
 queue/topic resource on the qpidd broker in band.   For example:
 $ QPID_LOAD_MODULE=amqpc.so ./spout --connection-options {protocol:amqp1.0} 
 TestQ;{create:always,node:{type:queue}}
 $ qpid-stat -q
 Queues
   queue   dur  autoDel  excl  msg   msgIn  msgOut  bytes  
 bytesIn  bytesOut  cons  bind
   
 ...
   TestQ1 1
   0  65 650 0 1
 This capability is not available when using the Messenger API.



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Commented] (PROTON-445) Binding installation ignores prefix

2013-10-25 Thread Darryl L. Pierce (JIRA)

[ 
https://issues.apache.org/jira/browse/PROTON-445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13805583#comment-13805583
 ] 

Darryl L. Pierce commented on PROTON-445:
-

Another suggestion, if we're to override where each language wants extensions 
installed, would be to have binding-specific variables (RUBY_INSTALL_DIR, 
PERL_INSTALL_DIR, PYTHON_INSTALL_DIR) that can be overridden by the developer 
if needed. By default the value for each variable would be what's returned by 
the language but which can be overridden individually.

Also, if we used CMAKE_INSTALL_PREFIX, how would the developer specifically say 
_not_ to apply it to their binding installations? If they want to install 
Proton to /opt but have their language bindings go to the default place the 
build system wouldn't be able to differentiate.

 Binding installation ignores prefix
 ---

 Key: PROTON-445
 URL: https://issues.apache.org/jira/browse/PROTON-445
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-c
Affects Versions: 0.5
Reporter: Justin Ross
 Attachments: what-a-mess.txt


 It allows you *prepend* to the install prefix, but it gives you no way afaict 
 to actually change the prefix.
 This is the opposite of nice.  If you set a prefix for your build *and* you 
 try to get your bindings slotted in with them, via DESTDIR, you get this:
 # cmake -DCMAKE_INSTALL_PREFIX:PATH=/opt/myplace 
 /var/tmp/jross/baker/proton/source
 # make install DESTDIR=/opt/myplace
 /opt/myplace/usr/lib/python/*python files*
 /opt/myplace/opt/myplace/lib/*c files*
 ^^ Note /opt/myplace/opt/myplace, the first from DESTDIR, the second from 
 CMAKE_INSTALL_PREFIX
 What it is doing now is simply abuse of DESTDIR.  DESTDIR is intended to be a 
 mechanism for staged installs (packaging systems use this), and it cannot 
 function correctly as an override for prefix.
 http://www.gnu.org/prep/standards/html_node/DESTDIR.html
 My proposed solution to this is to stop this madness: make the binding 
 install honor CMAKE_INSTALL_PREFIX.  Let the developer be responsible for 
 choosing the right location for his or her distribution.



--
This message was sent by Atlassian JIRA
(v6.1#6144)