Re: How to blogs on Qpid

[Danushka Menikkumbura]

Using Qpid / AMQP with JMS

http://rajith.2rlabs.com/2008/06/08/axis2synapse-amqp-support-via-jms-transport-using-apache-qpid/ 



Using Qpid / AMQP with Axis2

http://wso2.org/library/3663


Would it be useful to create a page where we link useful and 
informative blog posting about Qpid?

Carl.



I suggest we have an "official" blog for Qpid itself.

Danushka

--
Danushka Menikkumbura
Technical Lead, WSO2 Inc.

blog : http://danushka-menikkumbura.blogspot.com/

http://wso2.com/ - "The Open Source SOA Company"

RE: [jira] Updated: (QPID-53) Create Project Logo

[Robbie Gemmell]

I don’t particularly like any of the Q's (though that one would look nicer with 
a smaller/no gap at the bottom I think) so I didn’t bother trying it with 
different versions.

I just figured that of the few designs that don’t have any real colour, 3 is 
the nicest and definitely worth considering, but not as it stood :)


Now, it appears to be nearing time to get up, so I think ill go to bed :)

Robbie

-Original Message-
From: William Henry [mailto:whe...@redhat.com] 
Sent: 16 January 2009 03:27
To: dev@qpid.apache.org
Subject: Re: [jira] Updated: (QPID-53) Create Project Logo[MESSAGE NOT SCANNED]

Cute.  Not mad about the 'Q', but cute.

William

- "Robbie Gemmell"  wrote:

> I thought number 3 was being a bit let down by its colour scheme, so
> what better way to inject some and a bit of Apache at the same
> time...my non-voting opinion on the logo issue :P
> 
> https://issues.apache.org/jira/secure/attachment/12398037/qpid_logo_small.png
> https://issues.apache.org/jira/secure/attachment/12398038/qpid_logo_medium.png
> 
> Robbie
> 
> 
> -Original Message-
> From: Robert Gemmell (JIRA) [mailto:qpid-...@incubator.apache.org] 
> Sent: 16 January 2009 02:43
> To: qpid-...@incubator.apache.org
> Subject: [jira] Updated: (QPID-53) Create Project Logo[MESSAGE NOT
> SCANNED]
> 
> 
>  [
> https://issues.apache.org/jira/browse/QPID-53?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
> ]
> 
> Robert Gemmell updated QPID-53:
> ---
> 
> Attachment: qpid_logo_medium.png
> qpid_logo_small.png
> 
> I thought number 3 was being a bit let down by its colour scheme, so
> what better way to inject some... :)
> 
> > Create Project Logo
> > ---
> >
> > Key: QPID-53
> > URL: https://issues.apache.org/jira/browse/QPID-53
> > Project: Qpid
> >  Issue Type: Task
> >Reporter: Debbie Moynihan
> >Priority: Minor
> > Attachments: MoreAMQPLogos.pdf, qpid_logo_medium.png,
> qpid_logo_small.png, QpidLOGOS1023.pdf
> >
> >
> > Create a logo for the project.  
> 
> -- 
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.

Re: [jira] Updated: (QPID-53) Create Project Logo

[William Henry]

Cute.  Not mad about the 'Q', but cute.

William

- "Robbie Gemmell"  wrote:

> I thought number 3 was being a bit let down by its colour scheme, so
> what better way to inject some and a bit of Apache at the same
> time...my non-voting opinion on the logo issue :P
> 
> https://issues.apache.org/jira/secure/attachment/12398037/qpid_logo_small.png
> https://issues.apache.org/jira/secure/attachment/12398038/qpid_logo_medium.png
> 
> Robbie
> 
> 
> -Original Message-
> From: Robert Gemmell (JIRA) [mailto:qpid-...@incubator.apache.org] 
> Sent: 16 January 2009 02:43
> To: qpid-...@incubator.apache.org
> Subject: [jira] Updated: (QPID-53) Create Project Logo[MESSAGE NOT
> SCANNED]
> 
> 
>  [
> https://issues.apache.org/jira/browse/QPID-53?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
> ]
> 
> Robert Gemmell updated QPID-53:
> ---
> 
> Attachment: qpid_logo_medium.png
> qpid_logo_small.png
> 
> I thought number 3 was being a bit let down by its colour scheme, so
> what better way to inject some... :)
> 
> > Create Project Logo
> > ---
> >
> > Key: QPID-53
> > URL: https://issues.apache.org/jira/browse/QPID-53
> > Project: Qpid
> >  Issue Type: Task
> >Reporter: Debbie Moynihan
> >Priority: Minor
> > Attachments: MoreAMQPLogos.pdf, qpid_logo_medium.png,
> qpid_logo_small.png, QpidLOGOS1023.pdf
> >
> >
> > Create a logo for the project.  
> 
> -- 
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.

RE: [jira] Updated: (QPID-53) Create Project Logo

[Robbie Gemmell]

I thought number 3 was being a bit let down by its colour scheme, so what 
better way to inject some and a bit of Apache at the same time...my non-voting 
opinion on the logo issue :P

https://issues.apache.org/jira/secure/attachment/12398037/qpid_logo_small.png
https://issues.apache.org/jira/secure/attachment/12398038/qpid_logo_medium.png

Robbie


-Original Message-
From: Robert Gemmell (JIRA) [mailto:qpid-...@incubator.apache.org] 
Sent: 16 January 2009 02:43
To: qpid-...@incubator.apache.org
Subject: [jira] Updated: (QPID-53) Create Project Logo[MESSAGE NOT SCANNED]


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

Robert Gemmell updated QPID-53:
---

Attachment: qpid_logo_medium.png
qpid_logo_small.png

I thought number 3 was being a bit let down by its colour scheme, so what 
better way to inject some... :)

> Create Project Logo
> ---
>
> Key: QPID-53
> URL: https://issues.apache.org/jira/browse/QPID-53
> Project: Qpid
>  Issue Type: Task
>Reporter: Debbie Moynihan
>Priority: Minor
> Attachments: MoreAMQPLogos.pdf, qpid_logo_medium.png, 
> qpid_logo_small.png, QpidLOGOS1023.pdf
>
>
> Create a logo for the project.  

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (QPID-53) Create Project Logo

[Robert Gemmell (JIRA)]

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

Robert Gemmell updated QPID-53:
---

Attachment: qpid_logo_medium.png
qpid_logo_small.png

I thought number 3 was being a bit let down by its colour scheme, so what 
better way to inject some... :)

> Create Project Logo
> ---
>
> Key: QPID-53
> URL: https://issues.apache.org/jira/browse/QPID-53
> Project: Qpid
>  Issue Type: Task
>Reporter: Debbie Moynihan
>Priority: Minor
> Attachments: MoreAMQPLogos.pdf, qpid_logo_medium.png, 
> qpid_logo_small.png, QpidLOGOS1023.pdf
>
>
> Create a logo for the project.  

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Planning M5/ or whatever we call it

[Carl Trieloff]

Robert Greig wrote:

2009/1/15 Aidan Skinner :
  

On Thu, Jan 15, 2009 at 11:48 AM, Gordon Sim  wrote:



If the features on the page for M5 are more, shall we say, aspirational -
let's use them as a roadmap for 2009.


I'm certainly keen on understanding how our roadmap will take us to the
point where all Qpid components interoperate with each other. If it is not
feasible for the next release thats fine.
  

I suspect the most achievable way to approach this is to refactor the
broker and improve the test coverage for M5, then add extra protocols
after that.



Let me play devil's advocate for a moment.

I buy the argument that a full java multi-protocol bonanza is not
achievable in M5 timeline. And I also agree that one of the key things
users want is a stable product even in unforseen production
circumstances, so flow to disk would seem to be an important feature
to add for M5.

So if we accept that M5 will be a stability release, do we want to
risk destabilising other areas by performing signfiicant refactoring?
Even with the best efforts for test coverage, you would have to be
honest to potential users to say that there is some degree of risk in
an M5 that also had significant refactoring.

So with that logic I'm led to the conclusion that M5 should be a
relatively focussed "stability and minor feature" release (for Java
broker at least) before it embarks upon major upheaval for M6. M6 will
probably really be a "point zero" release and users who demand total
production stability would only look to pick up M7 or M8.


based on this reasoning which I think is solid, we should pick a release 
and hit it hard with

the refactoring we want to do.

Carl.

Re: Planning M5/ or whatever we call it

[Carl Trieloff]

And I really think we should bin this silly Mx release numbering convention:-)

  

+1

For 5 I vote we drop the M.

Carl.

Re: Planning M5/ or whatever we call it

[Robert Greig]

2009/1/15 Aidan Skinner :
> On Thu, Jan 15, 2009 at 11:48 AM, Gordon Sim  wrote:
>
>>> If the features on the page for M5 are more, shall we say, aspirational -
>>> let's use them as a roadmap for 2009.
>>
>> I'm certainly keen on understanding how our roadmap will take us to the
>> point where all Qpid components interoperate with each other. If it is not
>> feasible for the next release thats fine.
>
> I suspect the most achievable way to approach this is to refactor the
> broker and improve the test coverage for M5, then add extra protocols
> after that.

Let me play devil's advocate for a moment.

I buy the argument that a full java multi-protocol bonanza is not
achievable in M5 timeline. And I also agree that one of the key things
users want is a stable product even in unforseen production
circumstances, so flow to disk would seem to be an important feature
to add for M5.

So if we accept that M5 will be a stability release, do we want to
risk destabilising other areas by performing signfiicant refactoring?
Even with the best efforts for test coverage, you would have to be
honest to potential users to say that there is some degree of risk in
an M5 that also had significant refactoring.

So with that logic I'm led to the conclusion that M5 should be a
relatively focussed "stability and minor feature" release (for Java
broker at least) before it embarks upon major upheaval for M6. M6 will
probably really be a "point zero" release and users who demand total
production stability would only look to pick up M7 or M8.

And I really think we should bin this silly Mx release numbering convention:-)

RG

Re: How to blogs on Qpid

[Carl Trieloff]

I have added http://cwiki.apache.org/confluence/display/qpid/FAQ

Add at will

If you have a question for the page, post it to the list, or add it

Carl.


Carl Trieloff wrote:


Using Qpid / AMQP with JMS

http://rajith.2rlabs.com/2008/06/08/axis2synapse-amqp-support-via-jms-transport-using-apache-qpid/ 



Using Qpid / AMQP with Axis2

http://wso2.org/library/3663


Would it be useful to create a page where we link useful and 
informative blog posting about Qpid?

Carl.

Re: How to blogs on Qpid

[Jonathan Robie]

Carl Trieloff wrote:
Would it be useful to create a page where we link useful and 
informative blog posting about Qpid?


As well as articles and such. Yes, it would be useful.

Jonathan

Re: Planning M5/ or whatever we call it

[Aidan Skinner]

On Thu, Jan 15, 2009 at 3:53 PM, Marnie McCormack
 wrote:

> Let's try to narrow this list down a bit for a target M5 timescale ?
>
> As we've chatted about, I agree we should timebox our releases. But I think
> the Doctor might struggle with that lot before end March :-)

Obviously it depends on how many people are working on it. I think I
could manage the changes to the store interface and contribute some
work on the test coverage front.

Other people have expressed an interest in working on the transport
layer, so hopefully they might speak up?

- Aidan
-- 
Apache Qpid - World Domination through Advanced Message Queueing
http://qpid.apache.org

[jira] Commented: (QPID-396) Broker OutOfMemory Error handling

[Marnie McCormack (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12664167#action_12664167
 ] 

Marnie McCormack commented on QPID-396:
---

We should not be attempting to perform any elegant client interaction on broker 
OOM. But we should go bang immediately on the broker side. Inherent in OOM 
scenarios is that you cannot (should never) assume there's enough memory to do 
anything else. We need to look at what (if anything) we need to do to encourage 
a clean store shutdown though.

> Broker OutOfMemory Error handling
> -
>
> Key: QPID-396
> URL: https://issues.apache.org/jira/browse/QPID-396
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: M1, M2
>Reporter: Martin Ritchie
>Assignee: Martin Ritchie
>
> When the broker runs out of memory the response to the client can be 
> unpredicatable. 
> If this is something that you believe may occur currently the best thing to 
> do is to ensure that you are not hammering the broker with data. A slight 
> pause between message sending should allow the broker time to throw the 
> OutOfMemory Error during the handling of one of the methods rather than at 
> the mina level when receiving the data. 
> This should allow the broker to write a ConnectionClose frame back to the 
> client. We could signal here that we are out of memory and stop listening for 
> new connectons that will cause further OoM Errors.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (QPID-1237) Queue creation via the session does not create and bind the queue on the broker.

[Marnie McCormack (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-1237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12664159#action_12664159
 ] 

Marnie McCormack commented on QPID-1237:


This is as old as the hills - in that Qpid has always worked like this.

> Queue creation via the session does not create and bind the queue on the 
> broker.
> 
>
> Key: QPID-1237
> URL: https://issues.apache.org/jira/browse/QPID-1237
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Client, JMS Compliance
>Affects Versions: M2, M2.1, M3, M4
>Reporter: Martin Ritchie
>
> Summary:
> Currently createQueue(String) and createTemporary* do not perform the 
> creation/binding on the broker.
> I don't believe there has been any changes here recently but we are seeing a 
> TCK failure that would suggest otherwise.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (QPID-1583) IP White/Black lists for virtual hosts

[Aidan Skinner (JIRA)]

IP White/Black lists for virtual hosts
--

 Key: QPID-1583
 URL: https://issues.apache.org/jira/browse/QPID-1583
 Project: Qpid
  Issue Type: New Feature
  Components: Java Broker
Affects Versions: M5
Reporter: Aidan Skinner
Assignee: Aidan Skinner
 Fix For: M5


Having white/black lists for connecting to a virtual host would be useful.

Questions:
- need to provide an easy way for operate to maintain, secure & backup this list
- should consider what to do if there file/props etc for this are 
corrupt/format wrong
- if possible, the security filtering this provides should be part of a 
potential chain of access REDUCING plugins so that this is easy to drop in and 
teams can potentially write their own reducing filter class and use abstraction 
to define in config for broker
- needs to be at vhost level, and potentially at queue level ?



Explicit allow/deny lists of connection patterns on virtualhosts in config.xml, 
existing ACL infrastructure for entities below that.

Pattern would be one of:
IP address
CIDR mask
regexp on hostname

Changes would not be possible while broker was running, the file would need to 
be editted and then the broker restarted. This avoids the necessity to consider 
what happens to existing connections which would be excluded by a new rule. 
Errors in configuration would prevent broker startup.

Implementation wise, a new IPRestriction class would extend ACLPlugin which 
listens for ConnectionOpen and checks against the list of rules.

AMQProtocolSession needs to expose access to the underlying socket. 

--- 

We may need to reconsider allowing changes to the lists while the broker is 
running. It would probably imply storing these outwith the main configuration 
file and instead having something else, potentially a properties file, which 
could be editted by the broker as it runs. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Planning M5/ or whatever we call it

[Marnie McCormack]

Let's try to narrow this list down a bit for a target M5 timescale ?

As we've chatted about, I agree we should timebox our releases. But I think
the Doctor might struggle with that lot before end March :-)

Bfn,
Marnie

On Thu, Jan 15, 2009 at 2:40 PM, Aidan Skinner  wrote:

>  On Thu, Jan 15, 2009 at 2:26 PM, Marnie McCormack
>  wrote:
> > On Thu, Jan 15, 2009 at 1:44 PM, Aidan Skinner  >wrote:
> >
> >> On Thu, Jan 15, 2009 at 11:48 AM, Gordon Sim  wrote:
> >>
> >> >> If the features on the page for M5 are more, shall we say,
> aspirational
> >> -
> >> >> let's use them as a roadmap for 2009.
> >> >
> >> > I'm certainly keen on understanding how our roadmap will take us to
> the
> >> > point where all Qpid components interoperate with each other. If it is
> >> not
> >> > feasible for the next release thats fine.
> >>
> >> I suspect the most achievable way to approach this is to refactor the
> >> broker and improve the test coverage for M5, then add extra protocols
> >> after that.
> >>
> >> What refactoring would you propose for M5 ?
>
> The modularisation and decoupling described at
> http://qpid.apache.org/java-broker-modularisation.html
>
> I'd probably start with the event model, I/O layer and peristance
> interfaces.
>
> Flow to disk will be a lot easier to implement with a clear seperation
> between a transaction log and a retrieval store (which are really two
> separate things).
>
> The event model and I/O layer are the areas that will require the most
> modification for implementing additional protocols and are currently,
> IMVHO, the messiest. If this was done right it would also allow us to
> address the problem with unbounded buffers (QPID-1447 and friends).
>
> The session and model changes aren't as large, and don't have as much
> of an impact.
>
> - Aidan
> --
> Apache Qpid - World Domination through Advanced Message Queueing
> http://qpid.apache.org
>

Re: svn commit: r734619 - /qpid/trunk/qpid/java/lib/

[Carl Trieloff]

Andrea Gazzarini wrote:

Hi Carl I saw that running the build-release-bin task on QMan a notice
file is copied under the (qman) root release folder but is the Qpid
(java) notice file.
Is that right or I should create a dedicated one for QMan? Note that
the same applies for readme
Regards
Andrea


adding a section to the root file for QMan is fine for now.

Carl.

Re: svn commit: r734619 - /qpid/trunk/qpid/java/lib/

[Andrea Gazzarini]

Hi Carl I saw that running the build-release-bin task on QMan a notice
file is copied under the (qman) root release folder but is the Qpid
(java) notice file.
Is that right or I should create a dedicated one for QMan? Note that
the same applies for readme
Regards
Andrea

On 1/15/09, Carl Trieloff  wrote:
>
> Andrea,
>
> Please add each additional project used to the notice file for QMan /
> Java & the license it uses. This
> will make life easier when we get to release time.
>
> Carl.
>
>
>
> agazzar...@apache.org wrote:
>> Author: agazzarini
>> Date: Wed Jan 14 23:17:57 2009
>> New Revision: 734619
>>
>> URL: http://svn.apache.org/viewvc?rev=734619&view=rev
>> Log:
>> QPID-1574 : Additional libraries needed for WS-DM features
>>
>> Added:
>> qpid/trunk/qpid/java/lib/javassist.jar   (with props)
>> qpid/trunk/qpid/java/lib/jetty-6.1.14.jar   (with props)
>> qpid/trunk/qpid/java/lib/jetty-util-6.1.14.jar   (with props)
>> qpid/trunk/qpid/java/lib/muse-core-2.2.0.jar   (with props)
>> qpid/trunk/qpid/java/lib/muse-platform-mini-2.2.0.jar   (with props)
>> qpid/trunk/qpid/java/lib/muse-util-2.2.0.jar   (with props)
>> qpid/trunk/qpid/java/lib/muse-util-qname-2.2.0.jar   (with props)
>> qpid/trunk/qpid/java/lib/muse-util-xml-2.2.0.jar   (with props)
>> qpid/trunk/qpid/java/lib/muse-wsa-soap-2.2.0.jar   (with props)
>> qpid/trunk/qpid/java/lib/muse-wsdm-muws-adv-api-2.2.0.jar   (with
>> props)
>> qpid/trunk/qpid/java/lib/muse-wsdm-muws-adv-impl-2.2.0.jar   (with
>> props)
>> qpid/trunk/qpid/java/lib/muse-wsdm-muws-api-2.2.0.jar   (with props)
>> qpid/trunk/qpid/java/lib/muse-wsdm-muws-impl-2.2.0.jar   (with props)
>> qpid/trunk/qpid/java/lib/muse-wsdm-wef-api-2.2.0.jar   (with props)
>> qpid/trunk/qpid/java/lib/muse-wsdm-wef-impl-2.2.0.jar   (with props)
>> qpid/trunk/qpid/java/lib/muse-wsn-api-2.2.0.jar   (with props)
>> qpid/trunk/qpid/java/lib/muse-wsn-impl-2.2.0.jar   (with props)
>> qpid/trunk/qpid/java/lib/muse-wsrf-api-2.2.0.jar   (with props)
>> qpid/trunk/qpid/java/lib/muse-wsrf-impl-2.2.0.jar   (with props)
>> qpid/trunk/qpid/java/lib/muse-wsrf-rmd-2.2.0.jar   (with props)
>> qpid/trunk/qpid/java/lib/muse-wsx-api-2.2.0.jar   (with props)
>> qpid/trunk/qpid/java/lib/muse-wsx-impl-2.2.0.jar   (with props)
>> qpid/trunk/qpid/java/lib/start.jar   (with props)
>> qpid/trunk/qpid/java/lib/wsdl4j-1.6.1.jar   (with props)
>> qpid/trunk/qpid/java/lib/xercesImpl-2.8.1.jar   (with props)
>> qpid/trunk/qpid/java/lib/xml-apis-1.3.03.jar   (with props)
>
>

-- 
Sent from my mobile device

Re: Planning M5/ or whatever we call it

[Aidan Skinner]

On Thu, Jan 15, 2009 at 2:26 PM, Marnie McCormack
 wrote:
> On Thu, Jan 15, 2009 at 1:44 PM, Aidan Skinner wrote:
>
>> On Thu, Jan 15, 2009 at 11:48 AM, Gordon Sim  wrote:
>>
>> >> If the features on the page for M5 are more, shall we say, aspirational
>> -
>> >> let's use them as a roadmap for 2009.
>> >
>> > I'm certainly keen on understanding how our roadmap will take us to the
>> > point where all Qpid components interoperate with each other. If it is
>> not
>> > feasible for the next release thats fine.
>>
>> I suspect the most achievable way to approach this is to refactor the
>> broker and improve the test coverage for M5, then add extra protocols
>> after that.
>>
>> What refactoring would you propose for M5 ?

The modularisation and decoupling described at
http://qpid.apache.org/java-broker-modularisation.html

I'd probably start with the event model, I/O layer and peristance interfaces.

Flow to disk will be a lot easier to implement with a clear seperation
between a transaction log and a retrieval store (which are really two
separate things).

The event model and I/O layer are the areas that will require the most
modification for implementing additional protocols and are currently,
IMVHO, the messiest. If this was done right it would also allow us to
address the problem with unbounded buffers (QPID-1447 and friends).

The session and model changes aren't as large, and don't have as much
of an impact.

- Aidan
-- 
Apache Qpid - World Domination through Advanced Message Queueing
http://qpid.apache.org

Re: Planning M5/ or whatever we call it

[Marnie McCormack]

On Thu, Jan 15, 2009 at 1:44 PM, Aidan Skinner wrote:

> On Thu, Jan 15, 2009 at 11:48 AM, Gordon Sim  wrote:
>
> >> If the features on the page for M5 are more, shall we say, aspirational
> -
> >> let's use them as a roadmap for 2009.
> >
> > I'm certainly keen on understanding how our roadmap will take us to the
> > point where all Qpid components interoperate with each other. If it is
> not
> > feasible for the next release thats fine.
>
> I suspect the most achievable way to approach this is to refactor the
> broker and improve the test coverage for M5, then add extra protocols
> after that.
>
> What refactoring would you propose for M5 ?

Re: Planning M5/ or whatever we call it

[Gordon Sim]

Aidan Skinner wrote:

On Thu, Jan 15, 2009 at 11:48 AM, Gordon Sim  wrote:


If the features on the page for M5 are more, shall we say, aspirational -
let's use them as a roadmap for 2009.

I'm certainly keen on understanding how our roadmap will take us to the
point where all Qpid components interoperate with each other. If it is not
feasible for the next release thats fine.


I suspect the most achievable way to approach this is to refactor the
broker and improve the test coverage for M5, then add extra protocols
after that.

Small, iterative improvements and frequent releases tends to go more
smoothly than hackfest + big push.


Fair enough; thats hard to argue with!

Re: qpid-config & some ideas.

[Gordon Sim]

Carl Trieloff wrote:

Something worth adding would be qpid-msg tool, which could
browse messages on a queue, dequeue a message to a file, move
messages from queue to queue and enqueue a message from a file.

That would be handy for testing, and debugging. 


There are a couple of test programs in cpp/src/tests that are not a 
million miles away:


sender:   sends messages whose content is taken from standard
  in; you can specify the exchange and routing key to
  use; optionally an EOS message can be sent

receiver: consumes messages and writes the content to standard
  out; you can specify the queue to pull from and acking
  frequency; you can either specify a number of messages
  or keep pulling until you receive an EOS

They are currently very much just testing and debugging utilities and 
not as fancy as the tool you are describing, but thought they were worth 
mentioning anyway.

How to blogs on Qpid

[Carl Trieloff]

Using Qpid / AMQP with JMS

http://rajith.2rlabs.com/2008/06/08/axis2synapse-amqp-support-via-jms-transport-using-apache-qpid/

Using Qpid / AMQP with Axis2

http://wso2.org/library/3663


Would it be useful to create a page where we link useful and informative 
blog posting about Qpid?

Carl.

Re: Planning M5/ or whatever we call it

[Aidan Skinner]

On Thu, Jan 15, 2009 at 11:48 AM, Gordon Sim  wrote:

>> If the features on the page for M5 are more, shall we say, aspirational -
>> let's use them as a roadmap for 2009.
>
> I'm certainly keen on understanding how our roadmap will take us to the
> point where all Qpid components interoperate with each other. If it is not
> feasible for the next release thats fine.

I suspect the most achievable way to approach this is to refactor the
broker and improve the test coverage for M5, then add extra protocols
after that.

Small, iterative improvements and frequent releases tends to go more
smoothly than hackfest + big push.

- Aidan
-- 
Apache Qpid - World Domination through Advanced Message Queueing
http://qpid.apache.org

Re: Some site re-org[MESSAGE NOT SCANNED]

[Carl Trieloff]

michael.j.billi...@jpmorgan.com wrote:

You should know that unsubscribe process is not working. Can someone address?

did you subscribe to the list before we had graduated?

Carl.

qpid-config & some ideas.

[Carl Trieloff]

I see that Ted has edited this page and wanted to call out a few things.

It looks like we can now configure any queue & exchange option
via qpid-config, these include:

http://qpid.apache.org/mgmtc.html

Add Queue Options:
   --durableQueue is durable
   --cluster-durableQueue becomes durable if there is only one functioning 
cluster node
   --file-count N (8)   Number of files in queue's persistence journal
   --file-size  N (24)  File size in pages (64Kib/page)
   --max-queue-size N   Maximum in-memory queue size as bytes
   --max-queue-count N  Maximum in-memory queue size as a number of messages
   --limit-policy [none | reject | flow-to-disk | ring | ring-strict]
Action taken when queue limit is reached:
none (default) - Use broker's default policy
reject - Reject enqueued messages
flow-to-disk   - Page messages to disk
ring   - Replace oldest unacquired message 
with new
ring-strict- Replace oldest message, reject if 
oldest is acquired
   --order [fifo | lvq | lvq-no-browse]
Set queue ordering policy:
fifo (default) - First in, first out
lvq- Last Value Queue ordering, allows 
queue browsing
lvq-no-browse  - Last Value Queue ordering, 
browsing clients may lose data
   --generate-queue-events N
If set to 1, every enqueue will generate an event that 
can be processed by
registered listeners (e.g. for replication). If set to 
2, events will be
generated for enqueues and dequeues

Add Exchange Options:
   --durableExchange is durable
   --sequence   Exchange will insert a 'qpid.msg_sequence' field in the message 
header
with a value that increments for each message forwarded.
   --iveExchange will behave as an 'initial-value-exchange', keeping a 
reference
to the last message forwarded and enqueuing that message to 
newly bound
queues.


in addition the tool can be used to test the current set properties of
a queue or exchange.

$ qpid-config queues
Queue Name  Attributes
=
pub_start  
pub_done   
sub_ready  
sub_done   
perftest0   --durable

reply-dhcp-100-18-254.bos.redhat.com.20713  auto-del excl
topic-dhcp-100-18-254.bos.redhat.com.20713  auto-del excl


IT you have not played with it it is worth a whirl...

Something worth adding would be qpid-msg tool, which could
browse messages on a queue, dequeue a message to a file, move
messages from queue to queue and enqueue a message from a file.

That would be handy for testing, and debugging. Maybe even in some
production admin use cases... anyone jump in.

Carl.

Re: Some site re-org[MESSAGE NOT SCANNED]

[michael . j . billings]

You should know that unsubscribe process is not working. Can someone address?


- Original Message -
From: "Marnie McCormack" [marnie.mccorm...@googlemail.com]
Sent: 01/15/2009 01:32 PM GMT
To: dev@qpid.apache.org; cctriel...@redhat.com
Subject: Re: Some site re-org[MESSAGE NOT SCANNED]



Ok, then go for it - pick one :-)

On Thu, Jan 15, 2009 at 1:13 PM, Carl Trieloff wrote:

>
>
> Personally I don't think it is a big deal, we can try something, if we
> don't like it we change it.
> Carl.
>
>
>
> Marnie McCormack wrote:
>
>> Now, a work of caution on this ...
>> Last time we got nowhere near agreement, and abandoned the debate. Turns
>> out
>> colours and logos evoke much strong feeling !
>>
>> I reckon pick two and vote on which one to have is the only way forward in
>> order to get a Yes at the end this time:-)
>>
>> I checked with Debbie on this last year and afaik they're all paid for and
>> we can use whicherever one we like from the existing set.
>>
>> If we want a new one, I guess we need to do it ourselves ?
>>
>> TTfn,
>> Marnie
>> PS 11 was prob my fav last time reading the archives !!
>>
>> On Wed, Jan 14, 2009 at 9:46 PM, William Henry  wrote:
>>
>>
>>
>>> I'm sure there is a group out there that might want to protest such a
>>> logo.
>>>
>>> Don't worry I won't be starting a group to protest the use of red
>>> bearded,
>>> green clad, "vertically challenged" men for football teams or breakfast
>>> cereals  :) I mean where did they get such stereo types?
>>>
>>> Now where did I put those lucky charms again? I had them a minute ago.
>>> Did
>>> you take them Jonathan? I'll box your ears.
>>>
>>> William
>>>
>>> - "Rajith Attapattu"  wrote:
>>>
>>>
>>>
 Thats the very first thing came to my mind :)
 I don't think it's a bad idea :)

 Rajith

 On Wed, Jan 14, 2009 at 2:45 PM, Jonathan Robie
 wrote:



> Hmmm, Cupid and Apache ... a fat baby with wings, a loin cloth, a
>
>
 feather,


> and a bow and arrow?
>
> Jonathan
>
>
> Rajith Attapattu wrote:
>
>
>
>> IIRC we didn't really agree on a logo.
>> So now that we have graduated maybe we should start that thread
>>
>>
> again.


> We could start with the existing logos attaches to that JIRA.
>>
>> Regards,
>>
>> Rajith
>>
>> On Wed, Jan 14, 2009 at 1:07 PM, Lahiru Gunathilake
>>
>>
> >>>

>  wrote:
>>>
>>>
>>
>>
>>
>>> Hi Robbie,
>>>
>>> How about adding AMQP ... something to the logo itself. Like this
>>> http://www.blish.com/
>>>
>>>
>>> Lahiru
>>>
>>> On Wed, Jan 14, 2009 at 9:52 AM, Robbie
>>>
>>>
>>  > Gemmell <
>>>
>>>
  gemme...@dcs.gla.ac.uk> wrote:
>>>
>>>
>>>
>>>
>>>
 I recalled seeing some logos buried in JIRA somewhere when I was


>>> reading


>  the
 mailing last backlogs :)

 https://issues.apache.org/jira/browse/QPID-53

 Robbie

 -Original Message-
 From: glah...@gmail.com [mailto:glah...@gmail.com] On Behalf Of


>>> Lahiru


>  Gunathilake
 Sent: 14 January 2009 17:21
 To: dev@qpid.apache.org
 Subject: Re: Some site re-org[MESSAGE NOT SCANNED]

 Hi all,

 How about creating a logo for Qpid and decorate the home page


>>> with it.


>  At least like this http://mina.apache.org/related-projects.html


>>> :-)


>  Lahiru

 On Wed, Jan 14, 2009 at 9:04 AM, Jonathan Robie
 wrote:





> Gordon Sim wrote:
>
>
>
>
>
>> We should check with ASF infra if we can put a mail footer on
>>
>>
> the mail


>
>>
>>> lists, with some test and link the home page etc.
>>>
>>>
>>>
>>>
>>>
>> I'm not hugely keen on that idea.
>>
>>
>>
>>
>>
> Doing this for the generated archives is probably sufficient.
>
>
 And the


>   footer can be quite small.
>
> Jonathan
>
>
>
>
>


>>> --
>>> Apache Qpid, Worlds dominant messaging middleware..!!!
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>
>
>
 --


>>>  > Regards,
>>>
>>>
 Rajith Attapattu
 Red Hat
 http://rajith.2rlabs.com/


>>>
>>
>>
>
>


Generally, this communication is for informational purposes only
and it is not intended as an offer or solicitation for the purchase
or sale of any financial ins

Re: Some site re-org[MESSAGE NOT SCANNED]

[Marnie McCormack]

Ok, then go for it - pick one :-)

On Thu, Jan 15, 2009 at 1:13 PM, Carl Trieloff wrote:

>
>
> Personally I don't think it is a big deal, we can try something, if we
> don't like it we change it.
> Carl.
>
>
>
> Marnie McCormack wrote:
>
>> Now, a work of caution on this ...
>> Last time we got nowhere near agreement, and abandoned the debate. Turns
>> out
>> colours and logos evoke much strong feeling !
>>
>> I reckon pick two and vote on which one to have is the only way forward in
>> order to get a Yes at the end this time:-)
>>
>> I checked with Debbie on this last year and afaik they're all paid for and
>> we can use whicherever one we like from the existing set.
>>
>> If we want a new one, I guess we need to do it ourselves ?
>>
>> TTfn,
>> Marnie
>> PS 11 was prob my fav last time reading the archives !!
>>
>> On Wed, Jan 14, 2009 at 9:46 PM, William Henry  wrote:
>>
>>
>>
>>> I'm sure there is a group out there that might want to protest such a
>>> logo.
>>>
>>> Don't worry I won't be starting a group to protest the use of red
>>> bearded,
>>> green clad, "vertically challenged" men for football teams or breakfast
>>> cereals  :) I mean where did they get such stereo types?
>>>
>>> Now where did I put those lucky charms again? I had them a minute ago.
>>> Did
>>> you take them Jonathan? I'll box your ears.
>>>
>>> William
>>>
>>> - "Rajith Attapattu"  wrote:
>>>
>>>
>>>
 Thats the very first thing came to my mind :)
 I don't think it's a bad idea :)

 Rajith

 On Wed, Jan 14, 2009 at 2:45 PM, Jonathan Robie
 wrote:



> Hmmm, Cupid and Apache ... a fat baby with wings, a loin cloth, a
>
>
 feather,


> and a bow and arrow?
>
> Jonathan
>
>
> Rajith Attapattu wrote:
>
>
>
>> IIRC we didn't really agree on a logo.
>> So now that we have graduated maybe we should start that thread
>>
>>
> again.


> We could start with the existing logos attaches to that JIRA.
>>
>> Regards,
>>
>> Rajith
>>
>> On Wed, Jan 14, 2009 at 1:07 PM, Lahiru Gunathilake
>>
>>
> >>>

>  wrote:
>>>
>>>
>>
>>
>>
>>> Hi Robbie,
>>>
>>> How about adding AMQP ... something to the logo itself. Like this
>>> http://www.blish.com/
>>>
>>>
>>> Lahiru
>>>
>>> On Wed, Jan 14, 2009 at 9:52 AM, Robbie
>>>
>>>
>>  > Gemmell <
>>>
>>>
  gemme...@dcs.gla.ac.uk> wrote:
>>>
>>>
>>>
>>>
>>>
 I recalled seeing some logos buried in JIRA somewhere when I was


>>> reading


>  the
 mailing last backlogs :)

 https://issues.apache.org/jira/browse/QPID-53

 Robbie

 -Original Message-
 From: glah...@gmail.com [mailto:glah...@gmail.com] On Behalf Of


>>> Lahiru


>  Gunathilake
 Sent: 14 January 2009 17:21
 To: dev@qpid.apache.org
 Subject: Re: Some site re-org[MESSAGE NOT SCANNED]

 Hi all,

 How about creating a logo for Qpid and decorate the home page


>>> with it.


>  At least like this http://mina.apache.org/related-projects.html


>>> :-)


>  Lahiru

 On Wed, Jan 14, 2009 at 9:04 AM, Jonathan Robie
 wrote:





> Gordon Sim wrote:
>
>
>
>
>
>> We should check with ASF infra if we can put a mail footer on
>>
>>
> the mail


>
>>
>>> lists, with some test and link the home page etc.
>>>
>>>
>>>
>>>
>>>
>> I'm not hugely keen on that idea.
>>
>>
>>
>>
>>
> Doing this for the generated archives is probably sufficient.
>
>
 And the


>   footer can be quite small.
>
> Jonathan
>
>
>
>
>


>>> --
>>> Apache Qpid, Worlds dominant messaging middleware..!!!
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>
>
>
 --


>>>  > Regards,
>>>
>>>
 Rajith Attapattu
 Red Hat
 http://rajith.2rlabs.com/


>>>
>>
>>
>
>

Re: Some site re-org[MESSAGE NOT SCANNED]

[Carl Trieloff]

Personally I don't think it is a big deal, we can try something, if we 
don't like it we change it.

Carl.


Marnie McCormack wrote:

Now, a work of caution on this ...
Last time we got nowhere near agreement, and abandoned the debate. Turns out
colours and logos evoke much strong feeling !

I reckon pick two and vote on which one to have is the only way forward in
order to get a Yes at the end this time:-)

I checked with Debbie on this last year and afaik they're all paid for and
we can use whicherever one we like from the existing set.

If we want a new one, I guess we need to do it ourselves ?

TTfn,
Marnie
PS 11 was prob my fav last time reading the archives !!

On Wed, Jan 14, 2009 at 9:46 PM, William Henry  wrote:

  

I'm sure there is a group out there that might want to protest such a logo.

Don't worry I won't be starting a group to protest the use of red bearded,
green clad, "vertically challenged" men for football teams or breakfast
cereals  :) I mean where did they get such stereo types?

Now where did I put those lucky charms again? I had them a minute ago. Did
you take them Jonathan? I'll box your ears.

William

- "Rajith Attapattu"  wrote:



Thats the very first thing came to my mind :)
I don't think it's a bad idea :)

Rajith

On Wed, Jan 14, 2009 at 2:45 PM, Jonathan Robie
wrote:

  

Hmmm, Cupid and Apache ... a fat baby with wings, a loin cloth, a


feather,
  

and a bow and arrow?

Jonathan


Rajith Attapattu wrote:



IIRC we didn't really agree on a logo.
So now that we have graduated maybe we should start that thread
  

again.
  

We could start with the existing logos attaches to that JIRA.

Regards,

Rajith

On Wed, Jan 14, 2009 at 1:07 PM, Lahiru Gunathilake
  

  

wrote:



  

Hi Robbie,

How about adding AMQP ... something to the logo itself. Like this
http://www.blish.com/


Lahiru

On Wed, Jan 14, 2009 at 9:52 AM, Robbie


 > Gemmell <


gemme...@dcs.gla.ac.uk> wrote:





I recalled seeing some logos buried in JIRA somewhere when I was
  

reading
  

the
mailing last backlogs :)

https://issues.apache.org/jira/browse/QPID-53

Robbie

-Original Message-
From: glah...@gmail.com [mailto:glah...@gmail.com] On Behalf Of
  

Lahiru
  

Gunathilake
Sent: 14 January 2009 17:21
To: dev@qpid.apache.org
Subject: Re: Some site re-org[MESSAGE NOT SCANNED]

Hi all,

How about creating a logo for Qpid and decorate the home page
  

with it.
  

At least like this http://mina.apache.org/related-projects.html
  

:-)
  

Lahiru

On Wed, Jan 14, 2009 at 9:04 AM, Jonathan Robie
wrote:



  

Gordon Sim wrote:





We should check with ASF infra if we can put a mail footer on
  

the mail
  
  

lists, with some test and link the home page etc.





I'm not hugely keen on that idea.



  

Doing this for the generated archives is probably sufficient.


And the
  

footer can be quite small.

Jonathan




  

--
Apache Qpid, Worlds dominant messaging middleware..!!!








  


--
  

 > Regards,


Rajith Attapattu
Red Hat
http://rajith.2rlabs.com/
  


  

Re: Planning M5/ or whatever we call it

[Carl Trieloff]

Gordon Sim wrote:

Marnie McCormack wrote:
The build window for a March release is around 55 days (allowing for 
some
testing time). Not a huge amount, given utilisation etc. 


Maybe March is too soon? 


I would say end April at the latest.

Carl.

Re: svn commit: r734619 - /qpid/trunk/qpid/java/lib/

[Carl Trieloff]

Andrea,

Please add each additional project used to the notice file for QMan / 
Java & the license it uses. This

will make life easier when we get to release time.

Carl.



agazzar...@apache.org wrote:

Author: agazzarini
Date: Wed Jan 14 23:17:57 2009
New Revision: 734619

URL: http://svn.apache.org/viewvc?rev=734619&view=rev
Log:
QPID-1574 : Additional libraries needed for WS-DM features

Added:
qpid/trunk/qpid/java/lib/javassist.jar   (with props)
qpid/trunk/qpid/java/lib/jetty-6.1.14.jar   (with props)
qpid/trunk/qpid/java/lib/jetty-util-6.1.14.jar   (with props)
qpid/trunk/qpid/java/lib/muse-core-2.2.0.jar   (with props)
qpid/trunk/qpid/java/lib/muse-platform-mini-2.2.0.jar   (with props)
qpid/trunk/qpid/java/lib/muse-util-2.2.0.jar   (with props)
qpid/trunk/qpid/java/lib/muse-util-qname-2.2.0.jar   (with props)
qpid/trunk/qpid/java/lib/muse-util-xml-2.2.0.jar   (with props)
qpid/trunk/qpid/java/lib/muse-wsa-soap-2.2.0.jar   (with props)
qpid/trunk/qpid/java/lib/muse-wsdm-muws-adv-api-2.2.0.jar   (with props)
qpid/trunk/qpid/java/lib/muse-wsdm-muws-adv-impl-2.2.0.jar   (with props)
qpid/trunk/qpid/java/lib/muse-wsdm-muws-api-2.2.0.jar   (with props)
qpid/trunk/qpid/java/lib/muse-wsdm-muws-impl-2.2.0.jar   (with props)
qpid/trunk/qpid/java/lib/muse-wsdm-wef-api-2.2.0.jar   (with props)
qpid/trunk/qpid/java/lib/muse-wsdm-wef-impl-2.2.0.jar   (with props)
qpid/trunk/qpid/java/lib/muse-wsn-api-2.2.0.jar   (with props)
qpid/trunk/qpid/java/lib/muse-wsn-impl-2.2.0.jar   (with props)
qpid/trunk/qpid/java/lib/muse-wsrf-api-2.2.0.jar   (with props)
qpid/trunk/qpid/java/lib/muse-wsrf-impl-2.2.0.jar   (with props)
qpid/trunk/qpid/java/lib/muse-wsrf-rmd-2.2.0.jar   (with props)
qpid/trunk/qpid/java/lib/muse-wsx-api-2.2.0.jar   (with props)
qpid/trunk/qpid/java/lib/muse-wsx-impl-2.2.0.jar   (with props)
qpid/trunk/qpid/java/lib/start.jar   (with props)
qpid/trunk/qpid/java/lib/wsdl4j-1.6.1.jar   (with props)
qpid/trunk/qpid/java/lib/xercesImpl-2.8.1.jar   (with props)
qpid/trunk/qpid/java/lib/xml-apis-1.3.03.jar   (with props)

Re: Help for building java trunk

[Robbie Gemmell]

Perhaps you had already built it once at the top level when you ran the
sub-module's build, and it works after the second compile.

You were right as to why it happens though, and its a known issue. I
believe all such occurrences were removed not that long ago in order to
prevent this happening, but i recall seeing some traffic about threading
even more recently, so this is probably just a new occurrence of it
since then. 

Most people are using Java 6 compilers and targeting Java5, and it
doesnt show up in that scenario so its quite easy for it to go unseen.

Robbie

On Thu, 2009-01-15 at 13:10 +0100, Andrea Gazzarini wrote:
> Thanks Marnie, Thing is strange because the each module compiles fine..I
> have this error only when I run ant from the java root...
> Anyway, in order to see if my submitted work builds, I built common and
> client modules separately.
> 
> I will try your workaround too
> 
> Thanks again.
> 
> Andrea
> 
> 
> 2009/1/15 Marnie McCormack 
> 
> > Hi Andrea,
> >
> > There are some JIRAs around for this (the old ones are the best) - try
> > running again, I believe it works the second time :-)
> >
> > Marnie
> >
> > On Thu, Jan 15, 2009 at 9:12 AM, Andrea Gazzarini  > >wrote:
> >
> > > Hi,
> > > Ant issue has been solved! Finally I found ant and I'm able to run the
> > > build.
> > >
> > > Now I have a question : the build fails if java 1.5 is used...is that
> > > expected?
> > >
> > > Problem seems due to the fact that only from JDK1.6 the @Override
> > > annotation
> > > can be used for annotate an implementor method. JDK 1.5 requires that the
> > > method is really overriden. QpidThreadExecutor.execute(Runnable) seems to
> > > be
> > > an implementation of the Executor inteface.
> > >
> > >
> > >
> > 
> > > Buildfile: build.xml
> > > [echo] Running ant for module : client
> > >
> > > prepare:
> > >
> > > precompile:
> > >
> > > compile:
> > > [echo] Targeting : 1.5
> > >[javac] Compiling 134 source files to
> > > /x1/home/agazzarini/qpid/trunk/qpid/java/build/client/classes
> > >[javac]
> > >
> > >
> > /x1/home/agazzarini/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/transport/QpidThreadExecutor.java:9:
> > > method does not override a method from its superclass
> > >[javac] @Override
> > >[javac]  ^
> > >[javac] Note: Some input files use or override a deprecated API.
> > >[javac] Note: Recompile with -Xlint:deprecation for details.
> > >[javac] Note: Some input files use unchecked or unsafe operations.
> > >[javac] Note: Recompile with -Xlint:unchecked for details.
> > >[javac] 1 error
> > >
> > > BUILD FAILED
> > >
> > >
> > 
> > >
> > > Regards,
> > > Andrea
> > >
> > > 2009/1/15 Andrea Gazzarini 
> > >
> > > > Hi all,I just submitted QMan WS-DM so I'd need to run a manual build in
> > > > order to see that all is working...
> > > > I tried that on my machine and it builds ok but I'd like to run it on
> > the
> > > > apache machine too.
> > > > Is ant installed on that machine? If so How can I use it?
> > > >
> > > > Regards,
> > > > Andrea
> > > >
> > >
> >

Re: Planning M5/ or whatever we call it

[Marnie McCormack]

Hi,

I think (and some of this I wasn't around for) that we had agreed that more
was more on the release front. Certainly it gives us more
confidence/motivation to keep everything in good shape on trunk (i.e. test
it !).

For the Java releases, I'd personally rather keep an early & frequent
approach to releasing and have goals for each one that match up (loosely)
with the time available and the commitment in people terms to tasks. We can
plan different release schedules for the verious components, with an
agreement around interop testing, though.

If people know that they're going to be working on, let's start there and
then see if anyone has any time left.

I should know what that looks like for me next week. How is everyone else
fixed in terms of shouting out what they plan to do ?

Interop is a definite goal and an important one for us all I agree. On the
Java broker side I have come around (personally) to thinking that Flow To
Disk blows everything else of the water in importance terms. Let's make our
broker survive (without yeuch recovery) in all cases then do everything
else. Just seeing how that plans in/out with available resources to make it
happen.

I think we'll need to talk about which changes to branch for - some things
on the list are pretty big items that might well span more than one release
cycle.

Again, just my penny's worth.

Hth,
Marnie

On Thu, Jan 15, 2009 at 11:48 AM, Gordon Sim  wrote:

> Marnie McCormack wrote:
>
>> The build window for a March release is around 55 days (allowing for some
>> testing time). Not a huge amount, given utilisation etc.
>>
>
> Maybe March is too soon?
>
> If the features on the page for M5 are more, shall we say, aspirational -
>> let's use them as a roadmap for 2009.
>>
>
> I'm certainly keen on understanding how our roadmap will take us to the
> point where all Qpid components interoperate with each other. If it is not
> feasible for the next release thats fine.
>

Re: Help for building java trunk

[Andrea Gazzarini]

Thanks Marnie, Thing is strange because the each module compiles fine..I
have this error only when I run ant from the java root...
Anyway, in order to see if my submitted work builds, I built common and
client modules separately.

I will try your workaround too

Thanks again.

Andrea


2009/1/15 Marnie McCormack 

> Hi Andrea,
>
> There are some JIRAs around for this (the old ones are the best) - try
> running again, I believe it works the second time :-)
>
> Marnie
>
> On Thu, Jan 15, 2009 at 9:12 AM, Andrea Gazzarini  >wrote:
>
> > Hi,
> > Ant issue has been solved! Finally I found ant and I'm able to run the
> > build.
> >
> > Now I have a question : the build fails if java 1.5 is used...is that
> > expected?
> >
> > Problem seems due to the fact that only from JDK1.6 the @Override
> > annotation
> > can be used for annotate an implementor method. JDK 1.5 requires that the
> > method is really overriden. QpidThreadExecutor.execute(Runnable) seems to
> > be
> > an implementation of the Executor inteface.
> >
> >
> >
> 
> > Buildfile: build.xml
> > [echo] Running ant for module : client
> >
> > prepare:
> >
> > precompile:
> >
> > compile:
> > [echo] Targeting : 1.5
> >[javac] Compiling 134 source files to
> > /x1/home/agazzarini/qpid/trunk/qpid/java/build/client/classes
> >[javac]
> >
> >
> /x1/home/agazzarini/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/transport/QpidThreadExecutor.java:9:
> > method does not override a method from its superclass
> >[javac] @Override
> >[javac]  ^
> >[javac] Note: Some input files use or override a deprecated API.
> >[javac] Note: Recompile with -Xlint:deprecation for details.
> >[javac] Note: Some input files use unchecked or unsafe operations.
> >[javac] Note: Recompile with -Xlint:unchecked for details.
> >[javac] 1 error
> >
> > BUILD FAILED
> >
> >
> 
> >
> > Regards,
> > Andrea
> >
> > 2009/1/15 Andrea Gazzarini 
> >
> > > Hi all,I just submitted QMan WS-DM so I'd need to run a manual build in
> > > order to see that all is working...
> > > I tried that on my machine and it builds ok but I'd like to run it on
> the
> > > apache machine too.
> > > Is ant installed on that machine? If so How can I use it?
> > >
> > > Regards,
> > > Andrea
> > >
> >
>

[jira] Created: (QPID-1582) WS-Notifications

[Andrea Gazzarini (JIRA)]

WS-Notifications


 Key: QPID-1582
 URL: https://issues.apache.org/jira/browse/QPID-1582
 Project: Qpid
  Issue Type: Sub-task
  Components: Java Management : QMan
Affects Versions: M5
 Environment: J2SE 1.5 or higher
Reporter: Andrea Gazzarini
Assignee: Andrea Gazzarini
 Fix For: M5


JMX Notifications are already enabled on the JMX core.
Moreless the same thing must be implemented on the WS-DM adapter in order to 
enable management clients to subscribe and watch WS-Resources.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (QPID-1582) WS-Notifications

[Andrea Gazzarini (JIRA)]

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

Andrea Gazzarini updated QPID-1582:
---

Priority: Critical  (was: Major)

> WS-Notifications
> 
>
> Key: QPID-1582
> URL: https://issues.apache.org/jira/browse/QPID-1582
> Project: Qpid
>  Issue Type: Sub-task
>  Components: Java Management : QMan
>Affects Versions: M5
> Environment: J2SE 1.5 or higher
>Reporter: Andrea Gazzarini
>Assignee: Andrea Gazzarini
>Priority: Critical
> Fix For: M5
>
>   Original Estimate: 168h
>  Remaining Estimate: 168h
>
> JMX Notifications are already enabled on the JMX core.
> Moreless the same thing must be implemented on the WS-DM adapter in order to 
> enable management clients to subscribe and watch WS-Resources.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (QPID-1581) QMan admin console

[Andrea Gazzarini (JIRA)]

QMan admin console
--

 Key: QPID-1581
 URL: https://issues.apache.org/jira/browse/QPID-1581
 Project: Qpid
  Issue Type: Sub-task
  Components: Java Management : QMan
Affects Versions: M5
 Environment: J2SE 1.5 or higher
Reporter: Andrea Gazzarini
Assignee: Andrea Gazzarini
 Fix For: M5


The console will we web-based and therefore will be part of the preexisting 
qman.war module.

Features:

- System Overview : Riepilogue of all relevant module properties (version, 
version name, JVM enviroment, boot classpath, system properties, etc)
- System health & statistics : Analysis of module performance  & statistics for 
each WS-Resource;
- Resource management : Lets the user browse managed WS-resources. Each 
resources will be available under two different perspective : JMX (as an MBean) 
and WS-DM (as a WS-Resource). It will be possibile to interact with 
WS-Resources too (properties set & get, method invocation, etc..) 
- Hot logging reconfiguration


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (QPID-1496) Error: "Cannot handle multi-frame command segments yet"

[Gordon Sim (JIRA)]

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

Gordon Sim updated QPID-1496:
-

Priority: Minor  (was: Major)

Lowering the priority of this as after the initial occruence it was not 
reproducible. It may have been a dirty build or something transitory. Will 
leave it open for a shortwhile then close if there are no further reports of it.

> Error: "Cannot handle multi-frame command segments yet"
> ---
>
> Key: QPID-1496
> URL: https://issues.apache.org/jira/browse/QPID-1496
> Project: Qpid
>  Issue Type: Bug
>  Components: C++ Broker, C++ Client
>Affects Versions: M4
>Reporter: Gordon Sim
>Assignee: Gordon Sim
>Priority: Minor
>
> Code that uses qpid c++ client and has not been modified has recently started 
> reporting this error.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Planning M5/ or whatever we call it

[Gordon Sim]

Marnie McCormack wrote:

The build window for a March release is around 55 days (allowing for some
testing time). Not a huge amount, given utilisation etc. 


Maybe March is too soon?


If the features on the page for M5 are more, shall we say, aspirational -
let's use them as a roadmap for 2009.


I'm certainly keen on understanding how our roadmap will take us to the 
point where all Qpid components interoperate with each other. If it is 
not feasible for the next release thats fine.

[jira] Created: (QPID-1580) System Test Suite for WS-DM Adapter

[Andrea Gazzarini (JIRA)]

System Test Suite for WS-DM Adapter
---

 Key: QPID-1580
 URL: https://issues.apache.org/jira/browse/QPID-1580
 Project: Qpid
  Issue Type: Sub-task
  Components: Java Management : QMan
Affects Versions: M5
 Environment: J2SE 1.5 or higher
Reporter: Andrea Gazzarini
Assignee: Andrea Gazzarini
 Fix For: M5


That artifact will be part of qpid-systest-M5.jar library and it will contain 
system / integration test cases for WS-DM layer.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (QPID-1579) Unit Test Suite for WS-DM Adapter

[Andrea Gazzarini (JIRA)]

Unit Test Suite for WS-DM Adapter
-

 Key: QPID-1579
 URL: https://issues.apache.org/jira/browse/QPID-1579
 Project: Qpid
  Issue Type: Sub-task
  Components: Java Management : QMan
Affects Versions: M5
 Environment: J2SE 1.5 or higher
Reporter: Andrea Gazzarini
Assignee: Andrea Gazzarini
 Fix For: M5


That artifact will be part of management-client-test-M5.jar library and it will 
contain off-line test cases for WS-DM layer.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (QPID-1578) Set termination time (and therefore destroy them) on WS-resources when the corresponding Qpid object instance is removed.

[Andrea Gazzarini (JIRA)]

Set termination time (and therefore destroy them) on WS-resources when the 
corresponding Qpid object instance is removed.
-

 Key: QPID-1578
 URL: https://issues.apache.org/jira/browse/QPID-1578
 Project: Qpid
  Issue Type: Sub-task
  Components: Java Management : QMan
Affects Versions: M5
 Environment: J2SE 1.5 or higher
Reporter: Andrea Gazzarini
Assignee: Andrea Gazzarini
 Fix For: M5


When an obejct instance is removed on Qpid side (expired session, deleted 
queue, etc), QMan receives a content indication message which contains the 
expiration date for that object.

After that, the JMX core detects the corresponding MBean and unregister that 
from the MBeanServer. What needs to be done is, as conseguence of that event, 
to inform the WS-DM Adapter in order to let it set the termination time (and 
destroy) the corresponding WS-Resource.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Planning M5/ or whatever we call it

[Marnie McCormack]

Reading this, I think we're danger of being a little over-optimistic for M5
scope.

I'd be keen to take a more considered approach to scoping M5, with estimates
(very much ballpark) on the existing JIRAs we're looking at implementing. On
the Java broker side, we need to focus on robustness and reliability
(defects) as much as new features.

The build window for a March release is around 55 days (allowing for some
testing time). Not a huge amount, given utilisation etc. Might be good to
get people to start bagging the JIRAs they plan to work on in M5 and see
what we have from there. This would give us a tangible basis for a plan. And
it'd be nice to have one of those (loose & JIRA based) to make the release
easier to close out.

If the features on the page for M5 are more, shall we say, aspirational -
let's use them as a roadmap for 2009.

Just my tuppence. I'll be assigning JIRAs out across my friends & colleagues
when we have agreed what we're doing locally. That should help a bit.

Regards,
Marnie

On Thu, Jan 15, 2009 at 9:38 AM, Aidan Skinner wrote:

> On Wed, Jan 14, 2009 at 6:18 PM, Gordon Sim  wrote:
>
> > One specific question I'd like to raise is getting interop between all
> > components. I think that is a very important goal. Can we manage it for
> the
> > next release? I think the best way to do that would be 0-10 support for
> the
> > java broker.
>
> Adding more multiprotocol support to the java broker is definately
> something we should do. There'd need to be a bit of work done on
> modularisation[1] so that things don't get really horrid. 0-10 is a
> somewhat different beast from 0-8/0-9, and 1-0 looks substantially
> different as well. If we're talking about M5 in ~ a couple of months
> that's quite a lot of work to do in a relatively short time.
>
> - Aidan
>
> [1] See http://qpid.apache.org/java-broker-modularisation.html for
> some ideas on how that would look
>
> --
> Apache Qpid - World Domination through Advanced Message Queueing
> http://qpid.apache.org
>

Re: Help for building java trunk

[Marnie McCormack]

Hi Andrea,

There are some JIRAs around for this (the old ones are the best) - try
running again, I believe it works the second time :-)

Marnie

On Thu, Jan 15, 2009 at 9:12 AM, Andrea Gazzarini wrote:

> Hi,
> Ant issue has been solved! Finally I found ant and I'm able to run the
> build.
>
> Now I have a question : the build fails if java 1.5 is used...is that
> expected?
>
> Problem seems due to the fact that only from JDK1.6 the @Override
> annotation
> can be used for annotate an implementor method. JDK 1.5 requires that the
> method is really overriden. QpidThreadExecutor.execute(Runnable) seems to
> be
> an implementation of the Executor inteface.
>
>
> 
> Buildfile: build.xml
> [echo] Running ant for module : client
>
> prepare:
>
> precompile:
>
> compile:
> [echo] Targeting : 1.5
>[javac] Compiling 134 source files to
> /x1/home/agazzarini/qpid/trunk/qpid/java/build/client/classes
>[javac]
>
> /x1/home/agazzarini/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/transport/QpidThreadExecutor.java:9:
> method does not override a method from its superclass
>[javac] @Override
>[javac]  ^
>[javac] Note: Some input files use or override a deprecated API.
>[javac] Note: Recompile with -Xlint:deprecation for details.
>[javac] Note: Some input files use unchecked or unsafe operations.
>[javac] Note: Recompile with -Xlint:unchecked for details.
>[javac] 1 error
>
> BUILD FAILED
>
> 
>
> Regards,
> Andrea
>
> 2009/1/15 Andrea Gazzarini 
>
> > Hi all,I just submitted QMan WS-DM so I'd need to run a manual build in
> > order to see that all is working...
> > I tried that on my machine and it builds ok but I'd like to run it on the
> > apache machine too.
> > Is ant installed on that machine? If so How can I use it?
> >
> > Regards,
> > Andrea
> >
>

[jira] Updated: (QPID-1574) QMan WS-DM Adapter

[Andrea Gazzarini (JIRA)]

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

Andrea Gazzarini updated QPID-1574:
---

  Due Date: (was: 16/Jan/09)
   Description: 
This is a tracking issue for the progress in development of the WS-DM Adapter 
feature within the QMan Management Bridge module.

Regards,
Andrea


  was:
This is a tracking issue for the progress in development of the WS-DM Adapter 
feature within the QMan Management Bridge module.
This issue will be closed when a first working version will be submitted on the 
repository. Further improvements / sub-features will be traced with separated 
(sub) issues.

Regards,
Andrea


Remaining Estimate: 0h  (was: 48h)

> QMan WS-DM Adapter
> --
>
> Key: QPID-1574
> URL: https://issues.apache.org/jira/browse/QPID-1574
> Project: Qpid
>  Issue Type: New Feature
>  Components: Java Management : QMan
>Affects Versions: M5
> Environment: J2SE 1.5 or higher
>Reporter: Andrea Gazzarini
>Assignee: Andrea Gazzarini
> Fix For: M5
>
>   Original Estimate: 72h
>  Time Spent: 24h
>  Remaining Estimate: 0h
>
> This is a tracking issue for the progress in development of the WS-DM Adapter 
> feature within the QMan Management Bridge module.
> Regards,
> Andrea

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (QPID-1577) Use JAXB in order to dynamically create / populate wsdl:types/xsd:schema section for complex types.

[Andrea Gazzarini (JIRA)]

Use JAXB in order to dynamically create / populate wsdl:types/xsd:schema 
section for complex types.
---

 Key: QPID-1577
 URL: https://issues.apache.org/jira/browse/QPID-1577
 Project: Qpid
  Issue Type: Sub-task
  Components: Java Management : QMan
Affects Versions: M5
 Environment: J2SE 1.5 or higher
Reporter: Andrea Gazzarini
Assignee: Andrea Gazzarini
Priority: Minor
 Fix For: M5


When a new object instance is created on Qpid side, QMan receives content 
indication message about that.
On its side this is what happens:

- JMX core creates and register a new MBean for that instance; 
- WSDM Adapter creates a WS resource including WSDL and the corresponding 
capability.

If the incoming object instance has some complex property (i.e. Map or UUID) 
the WSDLBuilder, which is the component responsible to build wsdl for the 
resource, uses hard-coded statements in order to define schema section of wsdl.

Improvement should made in order to do that using automatic schema generation 
feature of JAXB API.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (QPID-1576) Missing file for Qpid C++ Documentation

[Gordon Sim (JIRA)]

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

Gordon Sim resolved QPID-1576.
--

Resolution: Fixed

I have fixed the link; thanks for pointing that out Larry!

> Missing file for Qpid  C++ Documentation
> 
>
> Key: QPID-1576
> URL: https://issues.apache.org/jira/browse/QPID-1576
> Project: Qpid
>  Issue Type: Bug
>  Components: website
> Environment: n/a
>Reporter: Larry Cohen
>
> The README file is missing from the "Qpid  C++ Documentation" area on the web 
> site.  
> Steps to reproduce:
> 1. Go to: http://qpid.apache.org/
> 2. Click: Documentation -> Qpid 'C++' Documentation -> README in subversion 
> for build instructions
> Tries to go to: 
> https://svn.apache.org/repos/asf/incubator/qpid/trunk/qpid/cpp/README 
> but result is:
> Page not found: Get "HTTP 404 Not Found" error.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Planning M5/ or whatever we call it

[Aidan Skinner]

On Wed, Jan 14, 2009 at 6:18 PM, Gordon Sim  wrote:

> One specific question I'd like to raise is getting interop between all
> components. I think that is a very important goal. Can we manage it for the
> next release? I think the best way to do that would be 0-10 support for the
> java broker.

Adding more multiprotocol support to the java broker is definately
something we should do. There'd need to be a bit of work done on
modularisation[1] so that things don't get really horrid. 0-10 is a
somewhat different beast from 0-8/0-9, and 1-0 looks substantially
different as well. If we're talking about M5 in ~ a couple of months
that's quite a lot of work to do in a relatively short time.

- Aidan

[1] See http://qpid.apache.org/java-broker-modularisation.html for
some ideas on how that would look

-- 
Apache Qpid - World Domination through Advanced Message Queueing
http://qpid.apache.org

Re: Some site re-org[MESSAGE NOT SCANNED]

[Marnie McCormack]

Now, a work of caution on this ...
Last time we got nowhere near agreement, and abandoned the debate. Turns out
colours and logos evoke much strong feeling !

I reckon pick two and vote on which one to have is the only way forward in
order to get a Yes at the end this time:-)

I checked with Debbie on this last year and afaik they're all paid for and
we can use whicherever one we like from the existing set.

If we want a new one, I guess we need to do it ourselves ?

TTfn,
Marnie
PS 11 was prob my fav last time reading the archives !!

On Wed, Jan 14, 2009 at 9:46 PM, William Henry  wrote:

> I'm sure there is a group out there that might want to protest such a logo.
>
> Don't worry I won't be starting a group to protest the use of red bearded,
> green clad, "vertically challenged" men for football teams or breakfast
> cereals  :) I mean where did they get such stereo types?
>
> Now where did I put those lucky charms again? I had them a minute ago. Did
> you take them Jonathan? I'll box your ears.
>
> William
>
> - "Rajith Attapattu"  wrote:
>
> > Thats the very first thing came to my mind :)
> > I don't think it's a bad idea :)
> >
> > Rajith
> >
> > On Wed, Jan 14, 2009 at 2:45 PM, Jonathan Robie
> > wrote:
> >
> > > Hmmm, Cupid and Apache ... a fat baby with wings, a loin cloth, a
> > feather,
> > > and a bow and arrow?
> > >
> > > Jonathan
> > >
> > >
> > > Rajith Attapattu wrote:
> > >
> > >> IIRC we didn't really agree on a logo.
> > >> So now that we have graduated maybe we should start that thread
> > again.
> > >> We could start with the existing logos attaches to that JIRA.
> > >>
> > >> Regards,
> > >>
> > >> Rajith
> > >>
> > >> On Wed, Jan 14, 2009 at 1:07 PM, Lahiru Gunathilake
> >  > >> >wrote:
> > >>
> > >>
> > >>
> > >>> Hi Robbie,
> > >>>
> > >>> How about adding AMQP ... something to the logo itself. Like this
> > >>> http://www.blish.com/
> > >>>
> > >>>
> > >>> Lahiru
> > >>>
> > >>> On Wed, Jan 14, 2009 at 9:52 AM, Robbie
>  > Gemmell <
> > >>> gemme...@dcs.gla.ac.uk> wrote:
> > >>>
> > >>>
> > >>>
> >  I recalled seeing some logos buried in JIRA somewhere when I was
> > reading
> >  the
> >  mailing last backlogs :)
> > 
> >  https://issues.apache.org/jira/browse/QPID-53
> > 
> >  Robbie
> > 
> >  -Original Message-
> >  From: glah...@gmail.com [mailto:glah...@gmail.com] On Behalf Of
> > Lahiru
> >  Gunathilake
> >  Sent: 14 January 2009 17:21
> >  To: dev@qpid.apache.org
> >  Subject: Re: Some site re-org[MESSAGE NOT SCANNED]
> > 
> >  Hi all,
> > 
> >  How about creating a logo for Qpid and decorate the home page
> > with it.
> > 
> >  At least like this http://mina.apache.org/related-projects.html
> > :-)
> > 
> >  Lahiru
> > 
> >  On Wed, Jan 14, 2009 at 9:04 AM, Jonathan Robie
> >  wrote:
> > 
> > 
> > 
> > > Gordon Sim wrote:
> > >
> > >
> > >
> > >> We should check with ASF infra if we can put a mail footer on
> > the mail
> > >>
> > >>
> > >>> lists, with some test and link the home page etc.
> > >>>
> > >>>
> > >>>
> > >> I'm not hugely keen on that idea.
> > >>
> > >>
> > >>
> > > Doing this for the generated archives is probably sufficient.
> > And the
> > > footer can be quite small.
> > >
> > > Jonathan
> > >
> > >
> > >
> > 
> > 
> > >>> --
> > >>> Apache Qpid, Worlds dominant messaging middleware..!!!
> > >>>
> > >>>
> > >>>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >
> > >
> >
> >
> > --
>  > Regards,
> >
> > Rajith Attapattu
> > Red Hat
> > http://rajith.2rlabs.com/
>

Re: Help for building java trunk

[Andrea Gazzarini]

Hi,
Ant issue has been solved! Finally I found ant and I'm able to run the
build.

Now I have a question : the build fails if java 1.5 is used...is that
expected?

Problem seems due to the fact that only from JDK1.6 the @Override annotation
can be used for annotate an implementor method. JDK 1.5 requires that the
method is really overriden. QpidThreadExecutor.execute(Runnable) seems to be
an implementation of the Executor inteface.


Buildfile: build.xml
 [echo] Running ant for module : client

prepare:

precompile:

compile:
 [echo] Targeting : 1.5
[javac] Compiling 134 source files to
/x1/home/agazzarini/qpid/trunk/qpid/java/build/client/classes
[javac]
/x1/home/agazzarini/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/transport/QpidThreadExecutor.java:9:
method does not override a method from its superclass
[javac] @Override
[javac]  ^
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
[javac] 1 error

BUILD FAILED


Regards,
Andrea

2009/1/15 Andrea Gazzarini 

> Hi all,I just submitted QMan WS-DM so I'd need to run a manual build in
> order to see that all is working...
> I tried that on my machine and it builds ok but I'd like to run it on the
> apache machine too.
> Is ant installed on that machine? If so How can I use it?
>
> Regards,
> Andrea
>