On 04/24/2010 02:52 AM, Eric Li wrote:
Thanks. I just gave a trial with the following command on ubuntu.
sudo ./src/qpidd --auth no --load-module /usr/lib/libssl3.so --ssl-cert-db
/home/amqp/server_db --ssl-cert-password-file /home/amqp/ok.pwd --ssl-cert-name
localhost.domain
2010-04-20
Forgotten method on SubscriptionManager
---
Key: QPID-2548
URL: https://issues.apache.org/jira/browse/QPID-2548
Project: Qpid
Issue Type: Bug
Components: C++ Client
Affects Versions: 0.6
Done.
Thanks
Francesco
Gordon Sim wrote:
On 04/26/2010 09:20 AM, francesco emmi wrote:
Hi all,
Sorry to borrow you,
I just would like to know if this patch will be applied. Otherwise I' ve
to change my application code.
Is there a Jira for it? We need you to grant your patch tp the ASF for
[
https://issues.apache.org/jira/browse/QPID-2548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gordon Sim reassigned QPID-2548:
Assignee: Gordon Sim
Forgotten method on SubscriptionManager
[
https://issues.apache.org/jira/browse/QPID-2548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
francesco updated QPID-2548:
-
Attachment: qpid.diff
Forgotten method on SubscriptionManager
---
[
https://issues.apache.org/jira/browse/QPID-2548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gordon Sim resolved QPID-2548.
--
Resolution: Fixed
Forgotten method on SubscriptionManager
---
[
https://issues.apache.org/jira/browse/QPID-1811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12860913#action_12860913
]
Andrew Stitcher commented on QPID-1811:
---
Applied patch for saslpasswd issue on trunk
Port qpid to FreeBSD
Key: QPID-2549
URL: https://issues.apache.org/jira/browse/QPID-2549
Project: Qpid
Issue Type: Bug
Components: C++ Broker
Affects Versions: 0.6
Environment: FreeBSD 8-CURRENT
[
https://issues.apache.org/jira/browse/QPID-1811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Stitcher updated QPID-1811:
--
Parent: QPID-2549
Issue Type: Sub-task (was: Bug)
Unable to compile qpid on FreeBSD
[
https://issues.apache.org/jira/browse/QPID-1811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Stitcher resolved QPID-1811.
---
Fix Version/s: 0.7
Resolution: Fixed
Unable to compile qpid on FreeBSD
[
https://issues.apache.org/jira/browse/QPID-2549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Stitcher updated QPID-2549:
--
Assignee: (was: Andrew Stitcher)
Labels: freebsd porting (was: )
Hello Andrew,
Could you please take a look at this?
Thank you!
Regards.
Begin forwarded message:
From: Bruno Matos (JIRA) qpid-...@incubator.apache.org
Date: 23 de abril de 2010 21:53:50 GMT+01:00
To: qpid-...@incubator.apache.org
Subject: [jira] Updated: (QPID-2543) Change uint to standard
I'd like to remove the old API examples and encourage people to use the
new API.
These examples are used by 'make check' to do cross-language
compatibility tests. I think we need to do these tests using the new API
and the new examples.
Are there any other tests that we do with 'make check'
[
https://issues.apache.org/jira/browse/QPID-2530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12860950#action_12860950
]
Martin Ritchie commented on QPID-2530:
--
Hi Robbie, can you take a look at these
I'd like to remove the old API examples and encourage people to use the
new API.
These examples are used by 'make check' to do cross-language
compatibility tests. I think we need to do these tests using the new API
and the new examples.
Are there any other tests that we do with 'make check'
Linking CXX shared library libqpidcommon.dylib
--
Key: QPID-2550
URL: https://issues.apache.org/jira/browse/QPID-2550
Project: Qpid
Issue Type: Improvement
Components: C++ Client
[
https://issues.apache.org/jira/browse/QPID-2550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12860968#action_12860968
]
Steve Huston commented on QPID-2550:
These are related to the Poller, AsynchIO
[
https://issues.apache.org/jira/browse/QPID-2550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12860972#action_12860972
]
Bruno Matos commented on QPID-2550:
---
I'll do my best! I think that is the same for
I just spent some time talking Joe Schaefer on #asfinfra, and he
suggests that we use svnpubsub to publish our DocBook, ePydoc, and
doxygen documents. svnpubsub uses a client-side daemon to listen for svn
updates, and checks them out to the desired directories on the web server.
I just spent some time talking Joe Schaefer on #asfinfra, and he
suggests that we use svnpubsub to publish our DocBook, ePydoc, and
doxygen documents. svnpubsub uses a client-side daemon to listen for svn
updates, and checks them out to the desired directories on the web server.
On Mon, 26 Apr 2010, Jonathan Robie wrote:
I just spent some time talking Joe Schaefer on #asfinfra, and he suggests
that we use svnpubsub to publish our DocBook, ePydoc, and doxygen documents.
svnpubsub uses a client-side daemon to listen for svn updates, and checks
them out to the desired
On Mon, 26 Apr 2010, Jonathan Robie wrote:
On 04/26/2010 03:22 PM, Justin Ross wrote:
Shuttling generated docs through subversion seems unnecessary. Any script
that can check for a change in a generated document can just as easily
check for a change in a source document. The only
On 04/26/2010 03:40 PM, Justin Ross wrote:
I think avoiding running programs on the frontline webserver is
perfectly reasonable. However, I don't think that quite argues
against a script.
We just need to figure out (A) where to run it and (B) how to schlep
the results. B is the more
From: Justin Ross [mailto:jr...@redhat.com]
On Mon, 26 Apr 2010, Jonathan Robie wrote:
On 04/26/2010 03:22 PM, Justin Ross wrote:
Shuttling generated docs through subversion seems
unnecessary. Any
script
that can check for a change in a generated document can
just as easily
On 04/26/2010 04:02 PM, Steve Huston wrote:
I think that automatically publishing web content based on source
check-ins is a bit too automagic for consistency and correctness to be
maintained. Also, I can imagine that there are source check-ins that
should not generate web updates (they're
On 04/26/2010 04:17 PM, Emmanuel Bourg wrote:
Jonathan Robie a écrit :
The other option we discussed on #asfinfra is to generate the docs
locally and use rsync. That works, but you have to wait perhaps an
hour for the documents to appear.
A solution might be to generate and publish the
On Mon, 26 Apr 2010, Steve Huston wrote:
I think that automatically publishing web content based on source
check-ins is a bit too automagic for consistency and correctness to be
maintained. Also, I can imagine that there are source check-ins that
should not generate web updates (they're
On Mon, 26 Apr 2010, Jonathan Robie wrote:
On 04/26/2010 04:17 PM, Emmanuel Bourg wrote:
Jonathan Robie a écrit :
The other option we discussed on #asfinfra is to generate the docs locally
and use rsync. That works, but you have to wait perhaps an hour for the
documents to appear.
A
On 04/26/2010 04:44 PM, Justin Ross wrote:
On Mon, 26 Apr 2010, Steve Huston wrote:
I think that automatically publishing web content based on source
check-ins is a bit too automagic for consistency and correctness to be
maintained. Also, I can imagine that there are source check-ins that
On 04/26/2010 04:47 PM, Justin Ross wrote:
Jonathan, is the one-hour delay a major factor? Adding an on-demand
publish-to-asf script that uses rsync or some equivalent seems like
the most attractive option to me.
It is for me. When I update documents, I can't see the updated documents
right
I completely agree with Steve here.
I really don't think we need upto the minute documentation in our
website (be it static html pages or docs generated through docbook).
This process is error prone and less than desirable !
On Mon, Apr 26, 2010 at 4:44 PM, Justin Ross jr...@redhat.com wrote:
On
On 04/26/2010 04:58 PM, Rajith Attapattu wrote:
I completely agree with Steve here.
I really don't think we need upto the minute documentation in our
website (be it static html pages or docs generated through docbook).
This process is error prone and less than desirable !
I believe
On Mon, Apr 26, 2010 at 5:05 PM, Jonathan Robie
jonathan.ro...@redhat.com wrote:
On 04/26/2010 04:58 PM, Rajith Attapattu wrote:
I completely agree with Steve here.
I really don't think we need upto the minute documentation in our
website (be it static html pages or docs generated through
On Mon, 26 Apr 2010, Jonathan Robie wrote:
On 04/26/2010 04:44 PM, Justin Ross wrote:
On Mon, 26 Apr 2010, Steve Huston wrote:
I think that automatically publishing web content based on source
check-ins is a bit too automagic for consistency and correctness to be
maintained. Also, I can
-Original Message-
From: Jonathan Robie [mailto:jonathan.ro...@redhat.com]
Sent: Monday, April 26, 2010 4:11 PM
To: dev@qpid.apache.org
Subject: Re: Publish generated docs with svnpubsub?
On 04/26/2010 04:02 PM, Steve Huston wrote:
I think that automatically publishing web
Justin Ross a écrit :
That said, if the asf infrastructure folks prefer it, I'll argue no
further.
The infra team explained their constraints on IRC:
- the Hudson server is not trusted and can't publish content to the web
site.
- rsync from the web server to pull the content is avoided for
36 matches
Mail list logo
