QMF2

[Stillwell]

Hi,

its been a little while since i last took a look at QMF2 has the python
library progressed at all beyond the prototype code that i found last year?

Thanks

James
-- 
View this message in context: 
http://old.nabble.com/QMF2-tp34883912p34883912.html
Sent from the Qpid Developers mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

qmf2 won't build on trunk

[Alan Conway]

I'm seeing these errors when trying to build the trunk:

In file included from 
/home/aconway/qpid/debug/bindings/qmf2/ruby/rubyRUBY_wrap.cxx:1883:0:
/home/aconway/qpid/qpid/cpp/include/qmf/exceptions.h:26:4: error: #error "The 
API defined in this file has been DEPRECATED and will be removed in the future."
/home/aconway/qpid/qpid/cpp/include/qmf/exceptions.h:27:4: error: #error "Define 
'QMF_USE_DEPRECATED_API' to enable continued use of the API."


If the API is deprecated then ideally we should stop using it. Failing that we 
should set QMF_USE_ DEPRECATED_API specifically for the files that need it so we 
can build the trunk.


Cheers
Alan.

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

Re: qmf2 won't build on trunk

[Chuck Rolke]

I think that the intent was to set QMF_USE_DEPRECATED_API on all
files that needed it. This build path must have slipped through
https://issues.apache.org/jira/browse/QPID-5369 and needs to be
touched to make it work.

-Chuck

- Original Message -
> From: "Alan Conway" 
> To: "Qpid Dev" 
> Sent: Wednesday, December 4, 2013 5:26:43 PM
> Subject: qmf2 won't build on trunk
> 
> I'm seeing these errors when trying to build the trunk:
> 
> In file included from
> /home/aconway/qpid/debug/bindings/qmf2/ruby/rubyRUBY_wrap.cxx:1883:0:
> /home/aconway/qpid/qpid/cpp/include/qmf/exceptions.h:26:4: error: #error "The
> API defined in this file has been DEPRECATED and will be removed in the
> future."
> /home/aconway/qpid/qpid/cpp/include/qmf/exceptions.h:27:4: error: #error
> "Define
> 'QMF_USE_DEPRECATED_API' to enable continued use of the API."
> 
> If the API is deprecated then ideally we should stop using it. Failing that
> we
> should set QMF_USE_ DEPRECATED_API specifically for the files that need it so
> we
> can build the trunk.
> 
> Cheers
> Alan.
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
> For additional commands, e-mail: dev-h...@qpid.apache.org
> 
> 

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

Re: qmf2 won't build on trunk

[Ken Giusti]

Chuck's correct - for some reason the ruby swig is not picking up the following 
change to cpp/include/qmf/qmf2.i:

https://svn.apache.org/viewvc/qpid/branches/0.26/qpid/cpp/include/qmf/qmf2.i?r1=1545842&r2=1545841&pathrev=1545842

Andrew and I have hit this before, spent some time on it and couldn't noodle 
out why ruby has this dependency issue.  The corresponding Python binding 
apparently doesn't and the cmake configurations are identical, AFAIKT.

I'll look into it a bit more, but for now you'll have to manually clean out the 
swig generated ruby sources from your build, sorry.

-K

- Original Message -
> From: "Chuck Rolke" 
> To: dev@qpid.apache.org
> Sent: Wednesday, December 4, 2013 7:06:30 PM
> Subject: Re: qmf2 won't build on trunk
> 
> I think that the intent was to set QMF_USE_DEPRECATED_API on all
> files that needed it. This build path must have slipped through
> https://issues.apache.org/jira/browse/QPID-5369 and needs to be
> touched to make it work.
> 
> -Chuck
> 
> - Original Message -
> > From: "Alan Conway" 
> > To: "Qpid Dev" 
> > Sent: Wednesday, December 4, 2013 5:26:43 PM
> > Subject: qmf2 won't build on trunk
> > 
> > I'm seeing these errors when trying to build the trunk:
> > 
> > In file included from
> > /home/aconway/qpid/debug/bindings/qmf2/ruby/rubyRUBY_wrap.cxx:1883:0:
> > /home/aconway/qpid/qpid/cpp/include/qmf/exceptions.h:26:4: error: #error
> > "The
> > API defined in this file has been DEPRECATED and will be removed in the
> > future."
> > /home/aconway/qpid/qpid/cpp/include/qmf/exceptions.h:27:4: error: #error
> > "Define
> > 'QMF_USE_DEPRECATED_API' to enable continued use of the API."
> > 
> > If the API is deprecated then ideally we should stop using it. Failing that
> > we
> > should set QMF_USE_ DEPRECATED_API specifically for the files that need it
> > so
> > we
> > can build the trunk.
> > 
> > Cheers
> > Alan.
> > 
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
> > For additional commands, e-mail: dev-h...@qpid.apache.org
> > 
> > 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
> For additional commands, e-mail: dev-h...@qpid.apache.org
> 
> 

-- 
-K

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

Re: qmf2 won't build on trunk

[Andrew Stitcher]

On Wed, 2013-12-04 at 17:26 -0500, Alan Conway wrote:
> I'm seeing these errors when trying to build the trunk:
> 
> In file included from 
> /home/aconway/qpid/debug/bindings/qmf2/ruby/rubyRUBY_wrap.cxx:1883:0:
> /home/aconway/qpid/qpid/cpp/include/qmf/exceptions.h:26:4: error: #error "The 
> API defined in this file has been DEPRECATED and will be removed in the 
> future."
> /home/aconway/qpid/qpid/cpp/include/qmf/exceptions.h:27:4: error: #error 
> "Define 
> 'QMF_USE_DEPRECATED_API' to enable continued use of the API."
> 
> If the API is deprecated then ideally we should stop using it. Failing that 
> we 
> should set QMF_USE_ DEPRECATED_API specifically for the files that need it so 
> we 
> can build the trunk.

I checked in a fix for this yesterday - (as part of QPID-5394) let me
know if it still fails.

Andrew



-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

QMF2, CMake, Windows and uint{32,64}_t

[Darryl L. Pierce]

I've enabled building QMF2 on Windows, but am stopped ATM due to
the ambiguous usage of uint32_t and uint64_t. Developer Studio isn't
used if the declarations want to use the boost:: or the Windows types.

It's very odd, since the same basic classes, such as AgentSession,
compile fine under for QMF on Windows.

Any ideas?

-- 
Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/



pgpIpddmLM43D.pgp
Description: PGP signature

Location for Java QMF2 code + QMF GUI

[Fraser Adams]

Hello all,
I'm looking to commit the Java QMF2 API, tools and GUI that I've 
hitherto had as tarballs here


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

It's all pretty self-contained and although has dependencies on the Qpid 
Java it doesn't impact anything in the main code base.


My preference for location would be in qpid/tools/src in a new 
subdirectory java which would seem to fit in given that there's a new 
ruby subdirectory that's just been added.


Does that seem reasonable?

Regards,
Frase



-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

Re: QMF2, CMake, Windows and uint{32,64}_t

[Andrew Stitcher]

On Mon, 2011-09-19 at 16:23 -0400, Darryl L. Pierce wrote:
> I've enabled building QMF2 on Windows, but am stopped ATM due to
> the ambiguous usage of uint32_t and uint64_t. Developer Studio isn't
> used if the declarations want to use the boost:: or the Windows types.

IIRC the uint32_t and uint64_t types have to be specially defined for
windows because they are not in the system header files (at least for
Dev Studio 2008). Is it possible that somehow the QMF2 build is picking
them up from multiple places?

> 
> It's very odd, since the same basic classes, such as AgentSession,
> compile fine under for QMF on Windows.

I'm fairly sure that the QMF (v1) C++ code has been building on windows
for some time.

Andrew



-
Apache Qpid - AMQP Messaging Implementation
Project:  http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org

Re: QMF2, CMake, Windows and uint{32,64}_t

[Darryl L. Pierce]

On Mon, Sep 19, 2011 at 04:39:14PM -0400, Andrew Stitcher wrote:
> On Mon, 2011-09-19 at 16:23 -0400, Darryl L. Pierce wrote:
> > I've enabled building QMF2 on Windows, but am stopped ATM due to
> > the ambiguous usage of uint32_t and uint64_t. Developer Studio isn't
> > used if the declarations want to use the boost:: or the Windows types.
> 
> IIRC the uint32_t and uint64_t types have to be specially defined for
> windows because they are not in the system header files (at least for
> Dev Studio 2008). Is it possible that somehow the QMF2 build is picking
> them up from multiple places?

The error I see is that the usage is "ambiguous" since, at compile time,
DevStudio is seeing uint32_t in both the boost namespace (which is
being used in the code) and also in qpid/sys/windows/IntegerTypes.h.

> > It's very odd, since the same basic classes, such as AgentSession,
> > compile fine under for QMF on Windows.
> 
> I'm fairly sure that the QMF (v1) C++ code has been building on windows
> for some time.

Which is why I'm trying to find what's different with QMFv2 vs v1.

-- 
Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/



pgp90k8I4sIAU.pgp
Description: PGP signature

Re: QMF2, CMake, Windows and uint{32,64}_t

[Andrew Stitcher]

On Mon, 2011-09-19 at 16:58 -0400, Darryl L. Pierce wrote:
> On Mon, Sep 19, 2011 at 04:39:14PM -0400, Andrew Stitcher wrote:
> > On Mon, 2011-09-19 at 16:23 -0400, Darryl L. Pierce wrote:
> > > I've enabled building QMF2 on Windows, but am stopped ATM due to
> > > the ambiguous usage of uint32_t and uint64_t. Developer Studio isn't
> > > used if the declarations want to use the boost:: or the Windows types.
> > 
> > IIRC the uint32_t and uint64_t types have to be specially defined for
> > windows because they are not in the system header files (at least for
> > Dev Studio 2008). Is it possible that somehow the QMF2 build is picking
> > them up from multiple places?
> 
> The error I see is that the usage is "ambiguous" since, at compile time,
> DevStudio is seeing uint32_t in both the boost namespace (which is
> being used in the code) and also in qpid/sys/windows/IntegerTypes.h.

Are the boost versions optional in some way, or perhaps dependent on
some boost include that we don't really need? I wouldn't expect any code
of ours to be needing boost versions of uint32_t etc so it's a little
puzzling they should be included.

Andrew



-
Apache Qpid - AMQP Messaging Implementation
Project:  http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org

RE: QMF2, CMake, Windows and uint{32,64}_t

[Steve Huston]

I faintly recall needing to remove some blanket "using boost" statements and 
adding explicit boost::namespaces on usage to avoid this type of problem.

If you get stuck feel free to reply with error messages.

-Steve

> -Original Message-
> From: Andrew Stitcher [mailto:astitc...@redhat.com]
> Sent: Monday, September 19, 2011 5:29 PM
> To: dev@qpid.apache.org
> Subject: Re: QMF2, CMake, Windows and uint{32,64}_t
>
> On Mon, 2011-09-19 at 16:58 -0400, Darryl L. Pierce wrote:
> > On Mon, Sep 19, 2011 at 04:39:14PM -0400, Andrew Stitcher wrote:
> > > On Mon, 2011-09-19 at 16:23 -0400, Darryl L. Pierce wrote:
> > > > I've enabled building QMF2 on Windows, but am stopped ATM due to
> > > > the ambiguous usage of uint32_t and uint64_t. Developer Studio
> > > > isn't used if the declarations want to use the boost:: or the 
> > > > Windows
> types.
> > >
> > > IIRC the uint32_t and uint64_t types have to be specially defined
> > > for windows because they are not in the system header files (at
> > > least for Dev Studio 2008). Is it possible that somehow the QMF2
> > > build is picking them up from multiple places?
> >
> > The error I see is that the usage is "ambiguous" since, at compile
> > time, DevStudio is seeing uint32_t in both the boost namespace (which
> > is being used in the code) and also in qpid/sys/windows/IntegerTypes.h.
>
> Are the boost versions optional in some way, or perhaps dependent on
> some boost include that we don't really need? I wouldn't expect any code 
> of
> ours to be needing boost versions of uint32_t etc so it's a little 
> puzzling they
> should be included.
>
> Andrew
>
>
>
> -
> Apache Qpid - AMQP Messaging Implementation
> Project:  http://qpid.apache.org
> Use/Interact: mailto:dev-subscr...@qpid.apache.org


-
Apache Qpid - AMQP Messaging Implementation
Project:  http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org

Re: QMF2, CMake, Windows and uint{32,64}_t

[Andrew Stitcher]

On Mon, 2011-09-19 at 16:58 -0400, Darryl L. Pierce wrote:
> On Mon, Sep 19, 2011 at 04:39:14PM -0400, Andrew Stitcher wrote:
> > On Mon, 2011-09-19 at 16:23 -0400, Darryl L. Pierce wrote:
> > > I've enabled building QMF2 on Windows, but am stopped ATM due to
> > > the ambiguous usage of uint32_t and uint64_t. Developer Studio isn't
> > > used if the declarations want to use the boost:: or the Windows types.
> > 
> > IIRC the uint32_t and uint64_t types have to be specially defined for
> > windows because they are not in the system header files (at least for
> > Dev Studio 2008). Is it possible that somehow the QMF2 build is picking
> > them up from multiple places?
> 
> The error I see is that the usage is "ambiguous" since, at compile time,
> DevStudio is seeing uint32_t in both the boost namespace (which is
> being used in the code) and also in qpid/sys/windows/IntegerTypes.h.

I'm guessing, but is there "using namespace boost" somewhere in the
offending files? That would have the effect of bringing all encountered
boost namespace symbols into the current namespace. If so then remove
this and add individual "using boost::..." for all necessary boost
symbols. Doing this is strongly recommended for production code in any
case.

Andrew



-
Apache Qpid - AMQP Messaging Implementation
Project:  http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org

Re: Location for Java QMF2 code + QMF GUI

[Ted Ross]

Frase,

Another possibility is qpid/extras/qmf.  That's where the Python 
implementation is.  We've used the extras directory as a place to put 
more layered functionality, or things that might someday become 
stand-alone projects.


-Ted

On 03/24/2013 03:15 AM, Fraser Adams wrote:

Hello all,
I'm looking to commit the Java QMF2 API, tools and GUI that I've 
hitherto had as tarballs here


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

It's all pretty self-contained and although has dependencies on the 
Qpid Java it doesn't impact anything in the main code base.


My preference for location would be in qpid/tools/src in a new 
subdirectory java which would seem to fit in given that there's a new 
ruby subdirectory that's just been added.


Does that seem reasonable?

Regards,
Frase



-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

Re: Location for Java QMF2 code + QMF GUI

[Fraser Adams]

Hi Ted,
I was torn between extras and tools. I guess what sold me on tools at 
the moment was because I've noticed that a ruby subdirectory has just 
been added there, so having a Java one too seems to make some sense. 
Also as part of the Java QMF stuff I've done I've striven to add ports 
of the "canonical" python tools (such as qpid-config). Now partly that's 
perhaps superfluous, but it does provide good illustration how to use 
the QMF API.


I'm a bit concerned that extras might be viewed a bit "second class 
citizen" and as I say it was the ruby stuff now in tools that swung it 
for me.


If there's strength of feeling that extras is more appropriate then 
that's fine and I'll be OK with that, but then the location of the ruby 
stuff seems inconsistent (I'm not knocking the ruby stuff, just trying 
to figure the most consistent place).


The "stand alone project" thing is interesting, there was talk of this 
for QMF last year but it didn't sprout wings, and I guess probably 
won't. Perhaps it might be time for a proper concerted think about 
"management" in general. Rob looks like he might announce some stuff 
from OASIS on AMQP management in the near future, so perhaps the time is 
ripe to move all the management stuff into a new space to start the ball 
rolling on that general trajectory?


I haven't made a proper start on this yet 'cause I ran into issues with 
the Java broker plugin stuff changing :-/ so I probably won't be able to 
make progress for a week or so 'cause I'm just about to go on holiday. 
I'll have email access but no development IT, it'll be good to have a 
discussion on management in general and what the thinking on the more 
"strategic" picture is. I think it's a good time to start this 
discussion, it's probably overdue given the divergence between the C++ 
and Java brokers.


Frase


On 25/03/13 12:54, Ted Ross wrote:

Frase,

Another possibility is qpid/extras/qmf.  That's where the Python 
implementation is.  We've used the extras directory as a place to put 
more layered functionality, or things that might someday become 
stand-alone projects.


-Ted

On 03/24/2013 03:15 AM, Fraser Adams wrote:

Hello all,
I'm looking to commit the Java QMF2 API, tools and GUI that I've 
hitherto had as tarballs here


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

It's all pretty self-contained and although has dependencies on the 
Qpid Java it doesn't impact anything in the main code base.


My preference for location would be in qpid/tools/src in a new 
subdirectory java which would seem to fit in given that there's a new 
ruby subdirectory that's just been added.


Does that seem reasonable?

Regards,
Frase



-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

Re: Location for Java QMF2 code + QMF GUI

[Rajith Attapattu]

Actually I'd like to take a step back and ask what are our plans for
QMF and management in general.
Fraser, this is in no way to discourage you or devalue your current
contribution.
But as you rightly pointed out in the later part of your email, we
should look at the bigger picture and see if we can align our selves
with the AMQP working group effort.

>From a community perspective, I'm not too keen to have our users to
start using java QMF given the uncertain future.
It might be a disservice to them.
But on the positive side, your contribution has forced us to discuss this again!

Regards,

Rajith

On Mon, Mar 25, 2013 at 2:32 PM, Fraser Adams
 wrote:
> Hi Ted,
> I was torn between extras and tools. I guess what sold me on tools at the
> moment was because I've noticed that a ruby subdirectory has just been added
> there, so having a Java one too seems to make some sense. Also as part of
> the Java QMF stuff I've done I've striven to add ports of the "canonical"
> python tools (such as qpid-config). Now partly that's perhaps superfluous,
> but it does provide good illustration how to use the QMF API.
>
> I'm a bit concerned that extras might be viewed a bit "second class citizen"
> and as I say it was the ruby stuff now in tools that swung it for me.
>
> If there's strength of feeling that extras is more appropriate then that's
> fine and I'll be OK with that, but then the location of the ruby stuff seems
> inconsistent (I'm not knocking the ruby stuff, just trying to figure the
> most consistent place).
>
> The "stand alone project" thing is interesting, there was talk of this for
> QMF last year but it didn't sprout wings, and I guess probably won't.
> Perhaps it might be time for a proper concerted think about "management" in
> general. Rob looks like he might announce some stuff from OASIS on AMQP
> management in the near future, so perhaps the time is ripe to move all the
> management stuff into a new space to start the ball rolling on that general
> trajectory?
>
> I haven't made a proper start on this yet 'cause I ran into issues with the
> Java broker plugin stuff changing :-/ so I probably won't be able to make
> progress for a week or so 'cause I'm just about to go on holiday. I'll have
> email access but no development IT, it'll be good to have a discussion on
> management in general and what the thinking on the more "strategic" picture
> is. I think it's a good time to start this discussion, it's probably overdue
> given the divergence between the C++ and Java brokers.
>
> Frase
>
>
>
> On 25/03/13 12:54, Ted Ross wrote:
>>
>> Frase,
>>
>> Another possibility is qpid/extras/qmf.  That's where the Python
>> implementation is.  We've used the extras directory as a place to put more
>> layered functionality, or things that might someday become stand-alone
>> projects.
>>
>> -Ted
>>
>> On 03/24/2013 03:15 AM, Fraser Adams wrote:
>>>
>>> Hello all,
>>> I'm looking to commit the Java QMF2 API, tools and GUI that I've hitherto
>>> had as tarballs here
>>>
>>> https://issues.apache.org/jira/browse/QPID-3675
>>>
>>> It's all pretty self-contained and although has dependencies on the Qpid
>>> Java it doesn't impact anything in the main code base.
>>>
>>> My preference for location would be in qpid/tools/src in a new
>>> subdirectory java which would seem to fit in given that there's a new ruby
>>> subdirectory that's just been added.
>>>
>>> Does that seem reasonable?
>>>
>>> Regards,
>>> Frase
>>>
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
>>> For additional commands, e-mail: dev-h...@qpid.apache.org
>>>
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
>> For additional commands, e-mail: dev-h...@qpid.apache.org
>>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
> For additional commands, e-mail: dev-h...@qpid.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

Re: Location for Java QMF2 code + QMF GUI

[Fraser Adams]

is discussion, it's probably overdue
given the divergence between the C++ and Java brokers.

Frase



On 25/03/13 12:54, Ted Ross wrote:

Frase,

Another possibility is qpid/extras/qmf.  That's where the Python
implementation is.  We've used the extras directory as a place to put more
layered functionality, or things that might someday become stand-alone
projects.

-Ted

On 03/24/2013 03:15 AM, Fraser Adams wrote:

Hello all,
I'm looking to commit the Java QMF2 API, tools and GUI that I've hitherto
had as tarballs here

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

It's all pretty self-contained and although has dependencies on the Qpid
Java it doesn't impact anything in the main code base.

My preference for location would be in qpid/tools/src in a new
subdirectory java which would seem to fit in given that there's a new ruby
subdirectory that's just been added.

Does that seem reasonable?

Regards,
Frase



-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

Re: Location for Java QMF2 code + QMF GUI

[Gordon Sim]

On 03/25/2013 07:25 PM, Fraser Adams wrote:

I'd have no problem migrating things to something new (sigh!!) but I
really think that the QMF Management GUI I put together is pretty good
and I had actually just got things working so that I could talk to both
the C++ and Java brokers using both qpid-config and the QMF GUI, that
consistency seemed pretty worthwhile IMHO.


I agree. The GUI tool was very nice and easy to use and fills a gap that 
no one else had plugged (i.e. a graphical tool for managing the c++ broker).


I have yet to try out the adapter to allow the same to be used against 
the java broker, but I must say I'm impressed with your achievement there.


I applaud your efforts in this area! Please do not be discouraged! The 
work you have done is very valuable now as is the insights you will now 
be able to bring to bear on future direction in this important area.


--Gordon.

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

Re: Location for Java QMF2 code + QMF GUI

[Rob Godfrey]

So, firstly I want to echo what Gordon has said.

Speaking for myself I am very grateful for the work you have been
doing on the QMF adapter for the Java broker.  I can only apologise
for some of the issues that you hve found in terms of
incompatibilities and I thank you for your patience in dealing with
them.

Going forward I certainly want Qpid (both the Java and C++ brokers, as
well as components coming out of the Proton workstream) to be using
the standardised AMQP 1.0 management... but while the standard is
currently focused on the mechanisms we have an opportunity as the Qpid
community to look at how type definitions and behaviours can be
standardised.  I think any such work can only benefit from starting
from the qork done in writing the QMF adapter.  I would hope that we
would be looking to adapt your GUI tool to use AMQP management as it
(AMQP management) matures (perhaps directly using AMQP over websockets
and a Proton JavaScript engine?).

In the meantime have you got a list of all the areas where the Java
Broker and C++ broker are incompatible?  I'm sure Gordon and I wouldbe
very interested in that and would do our utmost to try to narrow that
gap.

Thanks again,
Rob



On 25 March 2013 20:43, Gordon Sim  wrote:
> On 03/25/2013 07:25 PM, Fraser Adams wrote:
>>
>> I'd have no problem migrating things to something new (sigh!!) but I
>> really think that the QMF Management GUI I put together is pretty good
>> and I had actually just got things working so that I could talk to both
>> the C++ and Java brokers using both qpid-config and the QMF GUI, that
>> consistency seemed pretty worthwhile IMHO.
>
>
> I agree. The GUI tool was very nice and easy to use and fills a gap that no
> one else had plugged (i.e. a graphical tool for managing the c++ broker).
>
> I have yet to try out the adapter to allow the same to be used against the
> java broker, but I must say I'm impressed with your achievement there.
>
> I applaud your efforts in this area! Please do not be discouraged! The work
> you have done is very valuable now as is the insights you will now be able
> to bring to bear on future direction in this important area.
>
> --Gordon.
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
> For additional commands, e-mail: dev-h...@qpid.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

Re: Location for Java QMF2 code + QMF GUI

[Rajith Attapattu]

d a bit "second class
>>> citizen"
>>> and as I say it was the ruby stuff now in tools that swung it for me.
>>>
>>> If there's strength of feeling that extras is more appropriate then
>>> that's
>>> fine and I'll be OK with that, but then the location of the ruby stuff
>>> seems
>>> inconsistent (I'm not knocking the ruby stuff, just trying to figure the
>>> most consistent place).
>>>
>>> The "stand alone project" thing is interesting, there was talk of this
>>> for
>>> QMF last year but it didn't sprout wings, and I guess probably won't.
>>> Perhaps it might be time for a proper concerted think about "management"
>>> in
>>> general. Rob looks like he might announce some stuff from OASIS on AMQP
>>> management in the near future, so perhaps the time is ripe to move all
>>> the
>>> management stuff into a new space to start the ball rolling on that
>>> general
>>> trajectory?
>>>
>>> I haven't made a proper start on this yet 'cause I ran into issues with
>>> the
>>> Java broker plugin stuff changing :-/ so I probably won't be able to make
>>> progress for a week or so 'cause I'm just about to go on holiday. I'll
>>> have
>>> email access but no development IT, it'll be good to have a discussion on
>>> management in general and what the thinking on the more "strategic"
>>> picture
>>> is. I think it's a good time to start this discussion, it's probably
>>> overdue
>>> given the divergence between the C++ and Java brokers.
>>>
>>> Frase
>>>
>>>
>>>
>>> On 25/03/13 12:54, Ted Ross wrote:
>>>>
>>>> Frase,
>>>>
>>>> Another possibility is qpid/extras/qmf.  That's where the Python
>>>> implementation is.  We've used the extras directory as a place to put
>>>> more
>>>> layered functionality, or things that might someday become stand-alone
>>>> projects.
>>>>
>>>> -Ted
>>>>
>>>> On 03/24/2013 03:15 AM, Fraser Adams wrote:
>>>>>
>>>>> Hello all,
>>>>> I'm looking to commit the Java QMF2 API, tools and GUI that I've
>>>>> hitherto
>>>>> had as tarballs here
>>>>>
>>>>> https://issues.apache.org/jira/browse/QPID-3675
>>>>>
>>>>> It's all pretty self-contained and although has dependencies on the
>>>>> Qpid
>>>>> Java it doesn't impact anything in the main code base.
>>>>>
>>>>> My preference for location would be in qpid/tools/src in a new
>>>>> subdirectory java which would seem to fit in given that there's a new
>>>>> ruby
>>>>> subdirectory that's just been added.
>>>>>
>>>>> Does that seem reasonable?
>>>>>
>>>>> Regards,
>>>>> Frase
>>>>>
>>>>>
>>>>>
>>>>> -
>>>>> To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
>>>>> For additional commands, e-mail: dev-h...@qpid.apache.org
>>>>>
>>>>
>>>> -
>>>> To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
>>>> For additional commands, e-mail: dev-h...@qpid.apache.org
>>>>
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
>>> For additional commands, e-mail: dev-h...@qpid.apache.org
>>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
>> For additional commands, e-mail: dev-h...@qpid.apache.org
>>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
> For additional commands, e-mail: dev-h...@qpid.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

Re: Location for Java QMF2 code + QMF GUI

[Fraser Adams]

On 25/03/13 19:47, Rob Godfrey wrote:

In the meantime have you got a list of all the areas where the Java
Broker and C++ broker are incompatible?  I'm sure Gordon and I wouldbe
very interested in that and would do our utmost to try to narrow that
gap.

Thanks again,
Rob

Hi Rob, I'm afraid that I haven't got a full list as yet. The good news 
is that an awful lot is pretty similar. I noted some gaps in the Session 
objects in the Java broker - IIRC I think it was linking between 
session, subscription and queue. It's a little detail but it's useful in 
my GUI I can start with a connection and navigate through session and 
subscription to queue and vice versa I can start with a queue and 
navigate to connection. I suspect that I may be the only person who 
actually uses this behaviour :-D but I've also used it in another place 
where I audit queues and if someone tries to create or connect to a 
queue I don't have in a whitelist I log the connection information. 
Clearly I can't do that with the Java broker with this little piece of 
linkage missing. To be fair it's only really 'cause the Java broker 
model is a work in progress and it's marked as "TODO".


The main differences that I think cause pain is in the Queue object. It 
looks like there are a lot of differences between the Queue definitions 
for the C++ and Java brokers. For starters no ring queue in the Java 
broker (I use that all the time) but other differences relate to the 
fact that all the little config options seem to be different.


I found a list here 
https://cwiki.apache.org/confluence/display/qpid/Qpid+extensions+to+AMQP 
I don't know how complete it currently is but skimming through it it 
looks consistent with what I've noted. As you can see the bulk of the 
differences are in Queue.Declare. Clearly this also means that 
AddressStrings can't really be used interoperably between the two 
brokers - at least with the management interface it's possible to "shim" 
to some degree between QMF and the Java broker internal model to try to 
expose some level of commonality clearly that won't fix it when 
AddressStrings are being used.


I was planning on having a go adding stuff to the Java broker 
ConfiguredObjects when I'd got the other stuff committed, but the plugin 
changes and the questions about where to put the Java QMF stuff are 
likely to delay that a little.


Frase





-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

Re: Location for Java QMF2 code + QMF GUI

[Rob Godfrey]

oup effort.
> >>
> >>  From a community perspective, I'm not too keen to have our users to
> >> start using java QMF given the uncertain future.
> >> It might be a disservice to them.
> >> But on the positive side, your contribution has forced us to discuss
> this
> >> again!
> >>
> >> Regards,
> >>
> >> Rajith
> >>
> >> On Mon, Mar 25, 2013 at 2:32 PM, Fraser Adams
> >>  wrote:
> >>>
> >>> Hi Ted,
> >>> I was torn between extras and tools. I guess what sold me on tools at
> the
> >>> moment was because I've noticed that a ruby subdirectory has just been
> >>> added
> >>> there, so having a Java one too seems to make some sense. Also as part
> of
> >>> the Java QMF stuff I've done I've striven to add ports of the
> "canonical"
> >>> python tools (such as qpid-config). Now partly that's perhaps
> >>> superfluous,
> >>> but it does provide good illustration how to use the QMF API.
> >>>
> >>> I'm a bit concerned that extras might be viewed a bit "second class
> >>> citizen"
> >>> and as I say it was the ruby stuff now in tools that swung it for me.
> >>>
> >>> If there's strength of feeling that extras is more appropriate then
> >>> that's
> >>> fine and I'll be OK with that, but then the location of the ruby stuff
> >>> seems
> >>> inconsistent (I'm not knocking the ruby stuff, just trying to figure
> the
> >>> most consistent place).
> >>>
> >>> The "stand alone project" thing is interesting, there was talk of this
> >>> for
> >>> QMF last year but it didn't sprout wings, and I guess probably won't.
> >>> Perhaps it might be time for a proper concerted think about
> "management"
> >>> in
> >>> general. Rob looks like he might announce some stuff from OASIS on AMQP
> >>> management in the near future, so perhaps the time is ripe to move all
> >>> the
> >>> management stuff into a new space to start the ball rolling on that
> >>> general
> >>> trajectory?
> >>>
> >>> I haven't made a proper start on this yet 'cause I ran into issues with
> >>> the
> >>> Java broker plugin stuff changing :-/ so I probably won't be able to
> make
> >>> progress for a week or so 'cause I'm just about to go on holiday. I'll
> >>> have
> >>> email access but no development IT, it'll be good to have a discussion
> on
> >>> management in general and what the thinking on the more "strategic"
> >>> picture
> >>> is. I think it's a good time to start this discussion, it's probably
> >>> overdue
> >>> given the divergence between the C++ and Java brokers.
> >>>
> >>> Frase
> >>>
> >>>
> >>>
> >>> On 25/03/13 12:54, Ted Ross wrote:
> >>>>
> >>>> Frase,
> >>>>
> >>>> Another possibility is qpid/extras/qmf.  That's where the Python
> >>>> implementation is.  We've used the extras directory as a place to put
> >>>> more
> >>>> layered functionality, or things that might someday become stand-alone
> >>>> projects.
> >>>>
> >>>> -Ted
> >>>>
> >>>> On 03/24/2013 03:15 AM, Fraser Adams wrote:
> >>>>>
> >>>>> Hello all,
> >>>>> I'm looking to commit the Java QMF2 API, tools and GUI that I've
> >>>>> hitherto
> >>>>> had as tarballs here
> >>>>>
> >>>>> https://issues.apache.org/jira/browse/QPID-3675
> >>>>>
> >>>>> It's all pretty self-contained and although has dependencies on the
> >>>>> Qpid
> >>>>> Java it doesn't impact anything in the main code base.
> >>>>>
> >>>>> My preference for location would be in qpid/tools/src in a new
> >>>>> subdirectory java which would seem to fit in given that there's a new
> >>>>> ruby
> >>>>> subdirectory that's just been added.
> >>>>>
> >>>>> Does that seem reasonable?
> >>>>>
> >>>>> Regards,
> >>>>> Frase
> >>>>>
> >>>>>
> >>>>>
> >>>>> -
> >>>>> To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
> >>>>> For additional commands, e-mail: dev-h...@qpid.apache.org
> >>>>>
> >>>>
> >>>> -
> >>>> To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
> >>>> For additional commands, e-mail: dev-h...@qpid.apache.org
> >>>>
> >>>
> >>> -
> >>> To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
> >>> For additional commands, e-mail: dev-h...@qpid.apache.org
> >>>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
> >> For additional commands, e-mail: dev-h...@qpid.apache.org
> >>
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
> > For additional commands, e-mail: dev-h...@qpid.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
> For additional commands, e-mail: dev-h...@qpid.apache.org
>
>

Re: Location for Java QMF2 code + QMF GUI

[Rajith Attapattu]

On Mon, Mar 25, 2013 at 2:50 PM, Rajith Attapattu  wrote:
> Actually I'd like to take a step back and ask what are our plans for
> QMF and management in general.
> Fraser, this is in no way to discourage you or devalue your current
> contribution.
> But as you rightly pointed out in the later part of your email, we
> should look at the bigger picture and see if we can align our selves
> with the AMQP working group effort.
>
> From a community perspective, I'm not too keen to have our users to
> start using java QMF given the uncertain future.
> It might be a disservice to them.
> But on the positive side, your contribution has forced us to discuss this 
> again!

To further explain, we introduced the Qpid Messaging API and we have a
whole bunch of folks using it.
However there seems to be question marks about the future of it given
the emergence of Messenger.

We as a community has a duty towards our users. And it is from this
pov that I'm not so sure about if we want to add the Java QMF
implementation *as it is without further discussions*.
As Rob said, your contribution could be the basis for the new
management work. So again please don't feel discouraged.

Rajith

> Regards,
>
> Rajith
>
> On Mon, Mar 25, 2013 at 2:32 PM, Fraser Adams
>  wrote:
>> Hi Ted,
>> I was torn between extras and tools. I guess what sold me on tools at the
>> moment was because I've noticed that a ruby subdirectory has just been added
>> there, so having a Java one too seems to make some sense. Also as part of
>> the Java QMF stuff I've done I've striven to add ports of the "canonical"
>> python tools (such as qpid-config). Now partly that's perhaps superfluous,
>> but it does provide good illustration how to use the QMF API.
>>
>> I'm a bit concerned that extras might be viewed a bit "second class citizen"
>> and as I say it was the ruby stuff now in tools that swung it for me.
>>
>> If there's strength of feeling that extras is more appropriate then that's
>> fine and I'll be OK with that, but then the location of the ruby stuff seems
>> inconsistent (I'm not knocking the ruby stuff, just trying to figure the
>> most consistent place).
>>
>> The "stand alone project" thing is interesting, there was talk of this for
>> QMF last year but it didn't sprout wings, and I guess probably won't.
>> Perhaps it might be time for a proper concerted think about "management" in
>> general. Rob looks like he might announce some stuff from OASIS on AMQP
>> management in the near future, so perhaps the time is ripe to move all the
>> management stuff into a new space to start the ball rolling on that general
>> trajectory?
>>
>> I haven't made a proper start on this yet 'cause I ran into issues with the
>> Java broker plugin stuff changing :-/ so I probably won't be able to make
>> progress for a week or so 'cause I'm just about to go on holiday. I'll have
>> email access but no development IT, it'll be good to have a discussion on
>> management in general and what the thinking on the more "strategic" picture
>> is. I think it's a good time to start this discussion, it's probably overdue
>> given the divergence between the C++ and Java brokers.
>>
>> Frase
>>
>>
>>
>> On 25/03/13 12:54, Ted Ross wrote:
>>>
>>> Frase,
>>>
>>> Another possibility is qpid/extras/qmf.  That's where the Python
>>> implementation is.  We've used the extras directory as a place to put more
>>> layered functionality, or things that might someday become stand-alone
>>> projects.
>>>
>>> -Ted
>>>
>>> On 03/24/2013 03:15 AM, Fraser Adams wrote:
>>>>
>>>> Hello all,
>>>> I'm looking to commit the Java QMF2 API, tools and GUI that I've hitherto
>>>> had as tarballs here
>>>>
>>>> https://issues.apache.org/jira/browse/QPID-3675
>>>>
>>>> It's all pretty self-contained and although has dependencies on the Qpid
>>>> Java it doesn't impact anything in the main code base.
>>>>
>>>> My preference for location would be in qpid/tools/src in a new
>>>> subdirectory java which would seem to fit in given that there's a new ruby
>>>> subdirectory that's just been added.
>>>>
>>>> Does that seem reasonable?
>>>>
>>>> Regards,
>>>> Frase
>>>>
>>>>
>>>>
>>>> -
>>>> To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
>>>> For additional commands, e-mail: dev-h...@qpid.apache.org
>>>>
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
>>> For additional commands, e-mail: dev-h...@qpid.apache.org
>>>
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
>> For additional commands, e-mail: dev-h...@qpid.apache.org
>>

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

Re: Location for Java QMF2 code + QMF GUI

[Rob Godfrey]

On 25 March 2013 21:27, Fraser Adams  wrote:

> On 25/03/13 19:47, Rob Godfrey wrote:
>
>> In the meantime have you got a list of all the areas where the Java
>> Broker and C++ broker are incompatible?  I'm sure Gordon and I wouldbe
>> very interested in that and would do our utmost to try to narrow that
>> gap.
>>
>> Thanks again,
>> Rob
>>
>>  Hi Rob, I'm afraid that I haven't got a full list as yet. The good news
> is that an awful lot is pretty similar. I noted some gaps in the Session
> objects in the Java broker - IIRC I think it was linking between session,
> subscription and queue. It's a little detail but it's useful in my GUI I
> can start with a connection and navigate through session and subscription
> to queue and vice versa I can start with a queue and navigate to
> connection. I suspect that I may be the only person who actually uses this
> behaviour :-D but I've also used it in another place where I audit queues
> and if someone tries to create or connect to a queue I don't have in a
> whitelist I log the connection information. Clearly I can't do that with
> the Java broker with this little piece of linkage missing. To be fair it's
> only really 'cause the Java broker model is a work in progress and it's
> marked as "TODO".
>
> OK - I haven't looked at the Java code for that in a while (even though
there's a fair chance that I was the guilt party who wrote it - others
(Robbie, Alex, etc) tend to be far more conscientious about these things).
Raise a JIRA if it is causing an issue, and we (I) will try to fix it
sharpish :-)


> The main differences that I think cause pain is in the Queue object. It
> looks like there are a lot of differences between the Queue definitions for
> the C++ and Java brokers. For starters no ring queue in the Java broker (I
> use that all the time) but other differences relate to the fact that all
> the little config options seem to be different.
>

I found a list here https://cwiki.apache.org/**confluence/display/qpid/Qpid+
> **extensions+to+AMQP


Ah yes, I can vaguely recall creating that page a *long* time ago :-)


> I don't know how complete it currently is but skimming through it it looks
> consistent with what I've noted. As you can see the bulk of the differences
> are in Queue.Declare. Clearly this also means that AddressStrings can't
> really be used interoperably between the two brokers - at least with the
> management interface it's possible to "shim" to some degree between QMF and
> the Java broker internal model to try to expose some level of commonality
> clearly that won't fix it when AddressStrings are being used.
>
>
We should definitely try to address the cases where queue arguments simply
have different names.  Things like ring queues are a little odd.  In the
C++ broker they make a lot of sense because of the design of the persistent
store in use. Because the design of the store in the Java Broker is so
different it makes less sense to implement them in the same way... but
having some sort of size bounded queue would make sense... and we should
aim to provide a single name for this so they can be created consistently
across the two implementations.


> I was planning on having a go adding stuff to the Java broker
> ConfiguredObjects when I'd got the other stuff committed, but the plugin
> changes and the questions about where to put the Java QMF stuff are likely
> to delay that a little.
>
>
Again - apologies for this. Robbie is probably best placed to say when the
APIs are definitely "stable"... but when you check your stuff in we should
definitely make sure it is part of the Jenkins CI build so that if further
changes are made to the API we don't break the management code when we
check in such changes (or if we do we fix it ASAP).

Cheers,
Rob


> Frase
>
>
>
>
>
>
> --**--**-
> To unsubscribe, e-mail: 
> dev-unsubscribe@qpid.apache.**org
> For additional commands, e-mail: dev-h...@qpid.apache.org
>
>

Re: Location for Java QMF2 code + QMF GUI

[Rob Godfrey]

On 25 March 2013 21:32, Rajith Attapattu  wrote:

> On Mon, Mar 25, 2013 at 2:50 PM, Rajith Attapattu 
> wrote:
> > Actually I'd like to take a step back and ask what are our plans for
> > QMF and management in general.
> > Fraser, this is in no way to discourage you or devalue your current
> > contribution.
> > But as you rightly pointed out in the later part of your email, we
> > should look at the bigger picture and see if we can align our selves
> > with the AMQP working group effort.
> >
> > From a community perspective, I'm not too keen to have our users to
> > start using java QMF given the uncertain future.
> > It might be a disservice to them.
> > But on the positive side, your contribution has forced us to discuss
> this again!
>
>

To address this again.  Currently QMF is the only potential common "API"
for managing across the two brokers.  The emergence of a standardized AMQP
1.0 management may mean that we can change the underlying protocol being
used by tooling, and offer us the chance to provide tooling that works
against a greater number of implementations... But if Fraser can get his
code to compile against the moving goalpost that is the Java codebase, and
check it in to the Qpid project, then I think we can quite happily say that
we will continue to support it going forward until such point as everyone
is happy that alternatives such as AMQP 1.0 Management completely supplant
the QMF functionality.


> To further explain, we introduced the Qpid Messaging API and we have a
> whole bunch of folks using it.
> However there seems to be question marks about the future of it given
> the emergence of Messenger.
>
>
To my knowledge there is no doubt about the Messaging API.  It is
continuing to be supported and I believe Gordon is doing excellent work in
adding a 1-0 back end for it.


> We as a community has a duty towards our users. And it is from this
> pov that I'm not so sure about if we want to add the Java QMF
> implementation *as it is without further discussions*.
>

As someone with a strong interest in the Java Broker, I am personally happy
to sat that I want to add the Java QMF implementation.  The work in the
Java Broker to allow for such plugins was in some sense driven by the
desire to encourage such work.

-- Rob

As Rob said, your contribution could be the basis for the new
> management work. So again please don't feel discouraged.
>
> Rajith
>
> > Regards,
> >
> > Rajith
> >
> > On Mon, Mar 25, 2013 at 2:32 PM, Fraser Adams
> >  wrote:
> >> Hi Ted,
> >> I was torn between extras and tools. I guess what sold me on tools at
> the
> >> moment was because I've noticed that a ruby subdirectory has just been
> added
> >> there, so having a Java one too seems to make some sense. Also as part
> of
> >> the Java QMF stuff I've done I've striven to add ports of the
> "canonical"
> >> python tools (such as qpid-config). Now partly that's perhaps
> superfluous,
> >> but it does provide good illustration how to use the QMF API.
> >>
> >> I'm a bit concerned that extras might be viewed a bit "second class
> citizen"
> >> and as I say it was the ruby stuff now in tools that swung it for me.
> >>
> >> If there's strength of feeling that extras is more appropriate then
> that's
> >> fine and I'll be OK with that, but then the location of the ruby stuff
> seems
> >> inconsistent (I'm not knocking the ruby stuff, just trying to figure the
> >> most consistent place).
> >>
> >> The "stand alone project" thing is interesting, there was talk of this
> for
> >> QMF last year but it didn't sprout wings, and I guess probably won't.
> >> Perhaps it might be time for a proper concerted think about
> "management" in
> >> general. Rob looks like he might announce some stuff from OASIS on AMQP
> >> management in the near future, so perhaps the time is ripe to move all
> the
> >> management stuff into a new space to start the ball rolling on that
> general
> >> trajectory?
> >>
> >> I haven't made a proper start on this yet 'cause I ran into issues with
> the
> >> Java broker plugin stuff changing :-/ so I probably won't be able to
> make
> >> progress for a week or so 'cause I'm just about to go on holiday. I'll
> have
> >> email access but no development IT, it'll be good to have a discussion
> on
> >> management in general and what the thinking on the more "strategic"
>

Re: Location for Java QMF2 code + QMF GUI

[Fraser Adams]

On 25/03/13 20:21, Rajith Attapattu wrote:

f management tools that doesn't play nice with both
brokers.
I'm worried about adding another to the mix given that the Java broker
seems to have a different strategy for management.

Well yes and no. From what I've seen the Java broker has a pluggable 
approach (notwithstanding changes to the plugin API, but that's largely 
by the by).


As I said previously I released a QmfManagementPlugin for the Java 
Broker the other week and had that working with both qpid-config and the 
QMF GUI and in my setup I had I mixed economy of C++ and Java brokers 
controlled from a single management GUI. To my mind that seems like 
progress.


Ultimately the main differences we some differences in the underlying 
models - but nothing that appears insurmountable given modest effort.


At that point we'd no longer have "tools that doesn't play nice with 
both brokers " and the Java, Python and Ruby stuff would all work. At 
that point it would seem sensible to move forward working through the 
strategy for AMQP 1.0


It would seem nice to move forward from some point of (at least modest) 
consistency, then we can start as we intend to carry on - with a unified 
view.


Well that's my vision anyway and that's what I've been banging on about 
on the mailing lists for a fair time.



My "day job" is more of an architecture persuasion and as I've said 
several times I've been on the receiving end of having to make choices 
between products and to be frank I've sometimes struggled to justify 
Qpid primarily because of the ad hoc management (I refer to command line 
tools as not being very "CEO friendly"). I got away with it because of 
the performance, but the bottom line is that I suspect I'm not the only 
one in that position, which is one of the reasons I wrote the GUI and 
it's the reason that I made it "mobile friendly" too 'cause nice shiny 
page transitions catch the eye of casual observers (which is often where 
company "decision makers" sit). I think getting this stuff right is just 
as important as the underlying technology if we're serious about 
promoting AMQP and Qpid and getting as wide a buy in across the 
messaging industry as possible.


Frase







-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

Re: Location for Java QMF2 code + QMF GUI

[Rafael Schloming]

On Mon, Mar 25, 2013 at 4:45 PM, Rob Godfrey wrote:

> On 25 March 2013 21:32, Rajith Attapattu  wrote:
>
> > On Mon, Mar 25, 2013 at 2:50 PM, Rajith Attapattu 
> > wrote:
> > > Actually I'd like to take a step back and ask what are our plans for
> > > QMF and management in general.
> > > Fraser, this is in no way to discourage you or devalue your current
> > > contribution.
> > > But as you rightly pointed out in the later part of your email, we
> > > should look at the bigger picture and see if we can align our selves
> > > with the AMQP working group effort.
> > >
> > > From a community perspective, I'm not too keen to have our users to
> > > start using java QMF given the uncertain future.
> > > It might be a disservice to them.
> > > But on the positive side, your contribution has forced us to discuss
> > this again!
> >
> >
>
> To address this again.  Currently QMF is the only potential common "API"
> for managing across the two brokers.  The emergence of a standardized AMQP
> 1.0 management may mean that we can change the underlying protocol being
> used by tooling, and offer us the chance to provide tooling that works
> against a greater number of implementations... But if Fraser can get his
> code to compile against the moving goalpost that is the Java codebase, and
> check it in to the Qpid project, then I think we can quite happily say that
> we will continue to support it going forward until such point as everyone
> is happy that alternatives such as AMQP 1.0 Management completely supplant
> the QMF functionality.
>
>
> > To further explain, we introduced the Qpid Messaging API and we have a
> > whole bunch of folks using it.
> > However there seems to be question marks about the future of it given
> > the emergence of Messenger.
> >
> >
> To my knowledge there is no doubt about the Messaging API.  It is
> continuing to be supported and I believe Gordon is doing excellent work in
> adding a 1-0 back end for it.
>

+1

One of the primary goals of the messaging API was to provide users with a
seamless transition from 0-x to 1.0. There really are no question marks
about its future in this regard.

As one of the designers of both APIs I can confidently say they are quite a
bit more different than people tend to realize at this point. I think we
need to be careful not to encourage people to lump them into competition
with each other, and it's certainly inappropriate to be casually spreading
FUD about the future of the messaging API or any other qpid component.

--Rafael

Re: Location for Java QMF2 code + QMF GUI

[Fraser Adams]

On 25/03/13 20:38, Rob Godfrey wrote:


We should definitely try to address the cases where queue arguments simply
have different names.  Things like ring queues are a little odd.  In the
C++ broker they make a lot of sense because of the design of the persistent
store in use.
I'm not sure that it's just because of the design of the persistent 
store where ring queues make sense. I'm responsible for a large 
federated topology of C++ brokers and we use ring queues pretty much 
everywhere (without persistence).


We need a bounded buffer architecture so we erm rejected reject policy 
and are running at very high throughput so want to avoid the performance 
hit of persistence and our producers are real time components so we 
certainly don't want to use flow control to "push back" on the producers.


It might be a fairly "specialised" set of requirements, but I've 
certainly found ring queues to be really useful indeed in our system and 
would have balked (ha ha) had I not had the option of using them.




  Because the design of the store in the Java Broker is so
different it makes less sense to implement them in the same way... but
having some sort of size bounded queue would make sense... and we should
aim to provide a single name for this so they can be created consistently
across the two implementations.


The impression that I got about the Java broker queues is that it wasn't 
possible to specify a queue size per se but to implement "bounded" 
behaviour by the use of flow control, so when the number of 
messages/bytes hits a given limit the producer gets throttled. The C++ 
broker has added flow control from I think 0.12 - though I think the 
parameters for that are messages but the Java broker limits are in bytes 
(ggghhh).


None of this is really insurmountable, but getting the little things 
right I think will ultimately make a big difference.


From a user perspective some of this comes across rather as "black 
magic" the confluence wiki page that you put together describing some of 
the differences isn't exactly easy to find (I found it by accident and 
bookmarked it :-))


There's a bit of a common theme in my rambles isn't there :-)

Cheers,
Frase




-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

Re: Location for Java QMF2 code + QMF GUI

[Rob Godfrey]

On 25 March 2013 23:05, Fraser Adams  wrote:

> On 25/03/13 20:38, Rob Godfrey wrote:
>
>>
>> We should definitely try to address the cases where queue arguments simply
>> have different names.  Things like ring queues are a little odd.  In the
>> C++ broker they make a lot of sense because of the design of the
>> persistent
>> store in use.
>>
> I'm not sure that it's just because of the design of the persistent store
> where ring queues make sense. I'm responsible for a large federated
> topology of C++ brokers and we use ring queues pretty much everywhere
> (without persistence).
>
>
Sorry - I should have been clearer... The implementation of persistence in
the C++ broker pretty much forced them to define ring queues.  That's not
to say that there aren't non-persistent use cases for them.  The subtleties
are about what happens when consumption from the queue is not strictly
FIFO.  The C++ persistent queue implementation literally is a ring.  Thus
is you have non-FIFO consumption you can get "ring" overwriting even when
the number of unconsumed messages in the queue is less than the ring size.

The Java Broker doesn't have that sort of implementation.  The in-memory
queues are just (fancy) linked lists... and the disk storage is just a
transaction log.  As such it'd actually be quite hard to mimic exactly the
behaviour of the C++ queue.  If, OTOH, the actual requirement is just to
bound the unconsumed messages in a queue, that could certainly be
implemented as a policy.


> We need a bounded buffer architecture so we erm rejected reject policy and
> are running at very high throughput so want to avoid the performance hit of
> persistence and our producers are real time components so we certainly
> don't want to use flow control to "push back" on the producers.
>
> It might be a fairly "specialised" set of requirements, but I've certainly
> found ring queues to be really useful indeed in our system and would have
> balked (ha ha) had I not had the option of using them.
>
>
>
>Because the design of the store in the Java Broker is so
>> different it makes less sense to implement them in the same way... but
>> having some sort of size bounded queue would make sense... and we should
>> aim to provide a single name for this so they can be created consistently
>> across the two implementations.
>>
>>
>>  The impression that I got about the Java broker queues is that it wasn't
> possible to specify a queue size per se but to implement "bounded"
> behaviour by the use of flow control, so when the number of messages/bytes
> hits a given limit the producer gets throttled. The C++ broker has added
> flow control from I think 0.12 - though I think the parameters for that are
> messages but the Java broker limits are in bytes (ggghhh).
>
>
Yeah - this is driven by the fact that the user requirement we were meeting
was about not running out of memory so bytes makes more sense as the value
to limit.  Adding a count limit would not be too hard.  As above also
implementing some sort of discard policy based on bounding the number of
unconsumed messages in a queue is not that hard either.  It just wouldn't
be quite the same as the C++ ring queue.


> None of this is really insurmountable, but getting the little things right
> I think will ultimately make a big difference.
>
> From a user perspective some of this comes across rather as "black magic"
> the confluence wiki page that you put together describing some of the
> differences isn't exactly easy to find (I found it by accident and
> bookmarked it :-))
>
>
Yeah - we *really* need to sort our wiki and docs.  Having people such as
yourself who can point this out to us certainly helps :-)


> There's a bit of a common theme in my rambles isn't there :-)
>
>
Understood... Obviously any time you can spare to help us try to make
things better is much appreciated :-)

Cheers,
Rob


> Cheers,
>
> Frase
>
>
>
>
> --**--**-
> To unsubscribe, e-mail: 
> dev-unsubscribe@qpid.apache.**org
> For additional commands, e-mail: dev-h...@qpid.apache.org
>
>

Re: Location for Java QMF2 code + QMF GUI

[Gordon Sim]

On 03/25/2013 10:16 PM, Rob Godfrey wrote:

  The implementation of persistence in
the C++ broker pretty much forced them to define ring queues.


Actually the introduction of ring queues was not driven by the store at 
all. It came from use cases where build up of queues beyond a given 
point was undesirable and where the older messages could be ignored in 
those cases. They effectively implement a policy of 'only keep the last 
N messages', whereas say using a TTL would be a policy of 'only keep 
messages for T seconds'.



 That's not
to say that there aren't non-persistent use cases for them.  The subtleties
are about what happens when consumption from the queue is not strictly
FIFO.  The C++ persistent queue implementation literally is a ring.  Thus
is you have non-FIFO consumption you can get "ring" overwriting even when
the number of unconsumed messages in the queue is less than the ring size.


The store will not overwrite, it will simply refuse to enqueue more if 
there is no more space (that may indeed be when there is only one 
message still enqueued, if it happens to be at the start of the 'ring'). 
The ring buffer used in the journal is entirely distinct from the ring 
queues in memory (which can for example evict out of order, based on 
priority).


-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

Re: Location for Java QMF2 code + QMF GUI

[Rob Godfrey]

On 26 March 2013 12:45, Gordon Sim  wrote:

> On 03/25/2013 10:16 PM, Rob Godfrey wrote:
>
>>   The implementation of persistence in
>> the C++ broker pretty much forced them to define ring queues.
>>
>
> Actually the introduction of ring queues was not driven by the store at
> all. It came from use cases where build up of queues beyond a given point
> was undesirable and where the older messages could be ignored in those
> cases. They effectively implement a policy of 'only keep the last N
> messages', whereas say using a TTL would be a policy of 'only keep messages
> for T seconds'.
>
>
>   That's not
>> to say that there aren't non-persistent use cases for them.  The
>> subtleties
>> are about what happens when consumption from the queue is not strictly
>> FIFO.  The C++ persistent queue implementation literally is a ring.  Thus
>> is you have non-FIFO consumption you can get "ring" overwriting even when
>> the number of unconsumed messages in the queue is less than the ring size.
>>
>
> The store will not overwrite, it will simply refuse to enqueue more if
> there is no more space (that may indeed be when there is only one message
> still enqueued, if it happens to be at the start of the 'ring'). The ring
> buffer used in the journal is entirely distinct from the ring queues in
> memory (which can for example evict out of order, based on priority).
>
>
>
Many apologies for my misunderstanding...

In this case there shouldn't be a big barrier to implementing bounded queue
sizes in the same way in the Java Broker. I find the "ring" name somewhat
confusing then as the implementation is not actually a ring but simply a
bounded buffer where the oldest unconsumed message is discarded when the
queue size hits the bound.

Is there any special treatment of priority queues (do you discard lower
priority messages in preference to higher priority), or is the aging strict?

Cheers,
Rob


> --**--**-
> To unsubscribe, e-mail: 
> dev-unsubscribe@qpid.apache.**org
> For additional commands, e-mail: dev-h...@qpid.apache.org
>
>

Re: Location for Java QMF2 code + QMF GUI

[Gordon Sim]

On 03/26/2013 12:28 PM, Rob Godfrey wrote:

Many apologies for my misunderstanding...


No need, I can see where the confusion would arise, hence the clarification!


In this case there shouldn't be a big barrier to implementing bounded queue
sizes in the same way in the Java Broker.


The question is, if you set some sort of maximum depth on a queue, what 
do you do when you hit it? You can (a) throw some error, (b) drop 
certain messages to stay within the limit, (c) something else.


The 'ring' queue policy is really a policy to evict the oldest messages 
(or the lowest priority messages for a priority queue).



I find the "ring" name somewhat
confusing then as the implementation is not actually a ring but simply a
bounded buffer where the oldest unconsumed message is discarded when the
queue size hits the bound.


Yes, I've made a mess of naming in more than one area I'm afraid!


Is there any special treatment of priority queues (do you discard lower
priority messages in preference to higher priority), or is the aging strict?


Priority queues discard the lowest priority messages first (choosing the 
oldest messages within the same priority level for eviction).



-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

Re: Location for Java QMF2 code + QMF GUI

[Rob Godfrey]

On 26 March 2013 13:49, Gordon Sim  wrote:

> On 03/26/2013 12:28 PM, Rob Godfrey wrote:
>
>> Many apologies for my misunderstanding...
>>
>
> No need, I can see where the confusion would arise, hence the
> clarification!
>
>
>  In this case there shouldn't be a big barrier to implementing bounded
>> queue
>> sizes in the same way in the Java Broker.
>>
>
> The question is, if you set some sort of maximum depth on a queue, what do
> you do when you hit it? You can (a) throw some error, (b) drop certain
> messages to stay within the limit, (c) something else.
>
> The 'ring' queue policy is really a policy to evict the oldest messages
> (or the lowest priority messages for a priority queue).
>
>
>  I find the "ring" name somewhat
>> confusing then as the implementation is not actually a ring but simply a
>> bounded buffer where the oldest unconsumed message is discarded when the
>> queue size hits the bound.
>>
>
> Yes, I've made a mess of naming in more than one area I'm afraid!
>
>
>  Is there any special treatment of priority queues (do you discard lower
>> priority messages in preference to higher priority), or is the aging
>> strict?
>>
>
> Priority queues discard the lowest priority messages first (choosing the
> oldest messages within the same priority level for eviction).
>
>
>
OK... one final question... in the C++ broker, for a ring policy do
acquired but not yet acknowledged messages (e.g. messages that are
currently sitting in a client's prefetch buffer) count towards the limit?
If not what happens if such messages are released by the client at a
subsequent point?

Thanks for your help,
Rob


> --**--**-
> To unsubscribe, e-mail: 
> dev-unsubscribe@qpid.apache.**org
> For additional commands, e-mail: dev-h...@qpid.apache.org
>
>

Re: Location for Java QMF2 code + QMF GUI

[Robbie Gemmell]

I'll start by saying I also welcome the work fraser has done, and given it
is one of the primary reasons he was given commit rights look forward to it
making its way onto trunk.


On 25 March 2013 20:27, Fraser Adams  wrote:

> On 25/03/13 19:47, Rob Godfrey wrote:
>
>> In the meantime have you got a list of all the areas where the Java
>> Broker and C++ broker are incompatible?  I'm sure Gordon and I wouldbe
>> very interested in that and would do our utmost to try to narrow that
>> gap.
>>
>> Thanks again,
>> Rob
>>
>>  Hi Rob, I'm afraid that I haven't got a full list as yet. The good news
> is that an awful lot is pretty similar. I noted some gaps in the Session
> objects in the Java broker - IIRC I think it was linking between session,
> subscription and queue. It's a little detail but it's useful in my GUI I
> can start with a connection and navigate through session and subscription
> to queue and vice versa I can start with a queue and navigate to
> connection. I suspect that I may be the only person who actually uses this
> behaviour :-D but I've also used it in another place where I audit queues
> and if someone tries to create or connect to a queue I don't have in a
> whitelist I log the connection information. Clearly I can't do that with
> the Java broker with this little piece of linkage missing. To be fair it's
> only really 'cause the Java broker model is a work in progress and it's
> marked as "TODO".
>

That is something that was specifically considered as an end piece of
functionality, but just hasnt been implemented yet. Rob started by trying
to ensure that the HTTP interface covereed the existing JMX functionality
but the intention is definitely that it expands beyond that (and already
has, just not in this area yet, again basically due to priorities and time
constraints).

>
> The main differences that I think cause pain is in the Queue object. It
> looks like there are a lot of differences between the Queue definitions for
> the C++ and Java brokers. For starters no ring queue in the Java broker (I
> use that all the time) but other differences relate to the fact that all
> the little config options seem to be different.
>
>
Yes, the queues are the are of most difference, mainly due to different
points of implementation and probably specific requirements by particular
users of each broker over time (for example, whilst a few might actually
like it, most of the users I deal with in relation to the Java broker would
have a heart attack at the thought of ring queues hehe..and since noone has
ever really nagged us about it, its just been something that never hit the
top of any lists).


> I found a list here https://cwiki.apache.org/**
> confluence/display/qpid/Qpid+**extensions+to+AMQPI
>  don't know how complete it currently is but skimming through it it looks
> consistent with what I've noted. As you can see the bulk of the differences
> are in Queue.Declare. Clearly this also means that AddressStrings can't
> really be used interoperably between the two brokers - at least with the
> management interface it's possible to "shim" to some degree between QMF and
> the Java broker internal model to try to expose some level of commonality
> clearly that won't fix it when AddressStrings are being used.
>
> I was planning on having a go adding stuff to the Java broker
> ConfiguredObjects when I'd got the other stuff committed, but the plugin
> changes and the questions about where to put the Java QMF stuff are likely
> to delay that a little.
>
> Frase
>
>
If there is specific ideas you have, feel free to send out a mail and we
can discuss how best to do things :)

Robbie

Re: Location for Java QMF2 code + QMF GUI

[Gordon Sim]

On 03/26/2013 12:54 PM, Rob Godfrey wrote:

OK... one final question... in the C++ broker, for a ring policy do
acquired but not yet acknowledged messages (e.g. messages that are
currently sitting in a client's prefetch buffer) count towards the limit?


Yes

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Created] (QPID-3607) pkg config for qmf2 library

[Andrew Stitcher (Created) (JIRA)]

pkg config for qmf2 library
---

 Key: QPID-3607
 URL: https://issues.apache.org/jira/browse/QPID-3607
 Project: Qpid
  Issue Type: Improvement
  Components: C++ Client
Reporter: Andrew Stitcher


The current default qpid mke install installs include files for both the qpid 
messaging and qmf2 libraries, but only includes a pkg-config file for the qpid 
messaging libs.

Ideally to use qmf2 in an application make you'd just do something like:

  gcc app.cpp $(pkg-config --libs qmf2)


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
Apache Qpid - AMQP Messaging Implementation
Project:  http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org

[jira] [Assigned] (QPID-3607) pkg config for qmf2 library

[Andrew Stitcher (Assigned) (JIRA)]

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

Andrew Stitcher reassigned QPID-3607:
-

Assignee: Andrew Stitcher

> pkg config for qmf2 library
> ---
>
> Key: QPID-3607
> URL: https://issues.apache.org/jira/browse/QPID-3607
> Project: Qpid
>  Issue Type: Improvement
>  Components: C++ Client
>Reporter: Andrew Stitcher
>Assignee: Andrew Stitcher
>
> The current default qpid mke install installs include files for both the qpid 
> messaging and qmf2 libraries, but only includes a pkg-config file for the 
> qpid messaging libs.
> Ideally to use qmf2 in an application make you'd just do something like:
>   gcc app.cpp $(pkg-config --libs qmf2)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
Apache Qpid - AMQP Messaging Implementation
Project:  http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org

[jira] [Resolved] (QPID-3607) pkg config for qmf2 library

[Andrew Stitcher (Resolved) (JIRA)]

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

Andrew Stitcher resolved QPID-3607.
---

   Resolution: Fixed
Fix Version/s: 0.15

> pkg config for qmf2 library
> ---
>
> Key: QPID-3607
> URL: https://issues.apache.org/jira/browse/QPID-3607
> Project: Qpid
>  Issue Type: Improvement
>  Components: C++ Client
>Reporter: Andrew Stitcher
>Assignee: Andrew Stitcher
> Fix For: 0.15
>
>
> The current default qpid mke install installs include files for both the qpid 
> messaging and qmf2 libraries, but only includes a pkg-config file for the 
> qpid messaging libs.
> Ideally to use qmf2 in an application make you'd just do something like:
>   gcc app.cpp $(pkg-config --libs qmf2)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
Apache Qpid - AMQP Messaging Implementation
Project:  http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org

[jira] [Created] (QPID-5028) Qmf2 examples install script error

[Chuck Rolke (JIRA)]

Chuck Rolke created QPID-5028:
-

 Summary: Qmf2 examples install script error
 Key: QPID-5028
 URL: https://issues.apache.org/jira/browse/QPID-5028
 Project: Qpid
  Issue Type: Bug
  Components: Packaging
Affects Versions: 0.22
 Environment: Windows cmake install
Reporter: Chuck Rolke
Assignee: Chuck Rolke


Files are not located at CMAKE_CURRENT_SOURCE_DIR

--
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

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (QPID-5028) Qmf2 examples install script error

[Chuck Rolke (JIRA)]

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

Chuck Rolke commented on QPID-5028:
---

The windows installation of the qmf2 examples in cpp/bindings/qmf2/examples/cpp 
follows the same cmake script pattern of cpp/examples/messaging. In 
examples/messaging there is a .sln file and associated .vcproj files checked 
right in to the source tree. During the qmf2 installation these files are 
absent and the installation fails. 

Now the question is what to do about it. I think there are two choices:

1. Strip out the .sln and .vcproj files from examples/messaging and replace 
them with CMakeList.txt files. Add new cmake support for qmf2.
 (+) This is how the WinSDK delivers the examples/messaging example files. 
 (-) It imposes the burden of end users running cmake 
 (+) It generates solution (.sln) and project (.vcproj, .vcxproj) files for 32- 
and 64-bit architectures with any cmake-supported version of Visual Studio. 
This future-proofs the delivery of windows examples.

2. Add Visual Studio 2008 .sln and .vcproj files to the qmf2/examples directory.
 (+) If we use Choice 2 I suggest using VS2008 .sln and .vcproj examples. These 
can be upgraded in place by a customer with a later version of Visual Studio. 
 (-) VS2008 is three generations old. Adding files for it now seems dated and 
undesirable.

I favor Choice 1.
    
> Qmf2 examples install script error
> --
>
> Key: QPID-5028
> URL: https://issues.apache.org/jira/browse/QPID-5028
> Project: Qpid
>  Issue Type: Bug
>  Components: Packaging
>Affects Versions: 0.22
> Environment: Windows cmake install
>Reporter: Chuck Rolke
>Assignee: Chuck Rolke
>
> Files are not located at CMAKE_CURRENT_SOURCE_DIR

--
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

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (QPID-5028) Qmf2 examples install script error

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on QPID-5028:
---

Commit 1508967 from c...@apache.org in branch 'qpid/trunk'
[ https://svn.apache.org/r1508967 ]

QPID-5028: Qmf2 examples install script error
Don't try to install files that don't exist.
This patch may be superseded by new CMake files or by the addition of the .sln 
and .vcproj that are currently missing.

> Qmf2 examples install script error
> --
>
> Key: QPID-5028
> URL: https://issues.apache.org/jira/browse/QPID-5028
> Project: Qpid
>  Issue Type: Bug
>  Components: Packaging
>Affects Versions: 0.22
> Environment: Windows cmake install
>Reporter: Chuck Rolke
>Assignee: Chuck Rolke
>
> Files are not located at CMAKE_CURRENT_SOURCE_DIR

--
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

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (QPID-5028) Qmf2 examples install script error

[Justin Ross (JIRA)]

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

Justin Ross commented on QPID-5028:
---

Reviewed by Cliff.  Approved for 0.24.
    
> Qmf2 examples install script error
> --
>
> Key: QPID-5028
> URL: https://issues.apache.org/jira/browse/QPID-5028
> Project: Qpid
>  Issue Type: Bug
>  Components: Packaging
>Affects Versions: 0.22
> Environment: Windows cmake install
>Reporter: Chuck Rolke
>Assignee: Chuck Rolke
>
> Files are not located at CMAKE_CURRENT_SOURCE_DIR

--
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

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (QPID-5028) Qmf2 examples install script error

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on QPID-5028:
---

Commit 1509739 from c...@apache.org in branch 'qpid/branches/0.24'
[ https://svn.apache.org/r1509739 ]

QPID-5028: Qmf2 examples install script error - merge fix to 0.24 release branch
    
> Qmf2 examples install script error
> --
>
> Key: QPID-5028
> URL: https://issues.apache.org/jira/browse/QPID-5028
> Project: Qpid
>  Issue Type: Bug
>  Components: Packaging
>Affects Versions: 0.22
> Environment: Windows cmake install
>Reporter: Chuck Rolke
>Assignee: Chuck Rolke
>
> Files are not located at CMAKE_CURRENT_SOURCE_DIR

--
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

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Resolved] (QPID-5028) Qmf2 examples install script error

[Chuck Rolke (JIRA)]

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

Chuck Rolke resolved QPID-5028.
---

   Resolution: Fixed
Fix Version/s: 0.24

> Qmf2 examples install script error
> --
>
> Key: QPID-5028
> URL: https://issues.apache.org/jira/browse/QPID-5028
> Project: Qpid
>  Issue Type: Bug
>  Components: Packaging
>Affects Versions: 0.22
> Environment: Windows cmake install
>Reporter: Chuck Rolke
>Assignee: Chuck Rolke
> Fix For: 0.24
>
>
> Files are not located at CMAKE_CURRENT_SOURCE_DIR

--
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

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Created] (QPID-3675) New Feature Announce - Java QMF2 API Implementation.

[Fraser Adams (Created) (JIRA)]

New Feature Announce - Java QMF2 API Implementation.


 Key: QPID-3675
 URL: https://issues.apache.org/jira/browse/QPID-3675
 Project: Qpid
  Issue Type: New Feature
  Components: Java Management : QMF
Affects Versions: 0.12
 Environment: Java QMF2
Reporter: Fraser Adams


This is the first release of a QMF2 API Implementation for Java.

Features:
* Full Implementation of QMF2 Console, Agent and AgentExternal.
* Supports QMF2 Query Subscriptions on Agent/AgentExternal implementations.
* Emulates QMF2 Query Subscriptions on the Console side for the broker 
ManagementAgent by
  intercepting _data indications and filtering against QmfQuery. This is 
necessary as the
  ManagemetAgent doesn't yet support QMF2 style Query Subscriptions.
* Console supports Agent discovery via findAgent() method, which can support 
partial matches,
  which is useful because the full Agent name has a UUID representing the 
"instance" so it's hard
  to know the full name.
* QmfQuery supports regex matching.
* Supports QMF2 WorkItem Event model and in addition supports an alternative 
QmfEventListener 
  Event model, which is rather more like the JMS MessageListener model.

Example Tools Provided:
* ConnectionAudit: Audits connections to one or more Qpid message brokers 
against a whitelist.
* ConnectionLogger: A QMF2 class used to provide information about connections 
made to a broker.
* QpidConfig: QpidConfig is a fairly "literal" Java port of the python 
qpid-config tool. Uses pure 
  QMF2 for adding/deleting queues, exchanges & bindings this provides useful 
illustration of how 
  to do these things using the ManagementAgent method calls.
* QpidCtrl: A tool to allow QMF2 methods to be invoked from the command line.
* QpidPrintEvents: Collect and print events from one or more Qpid message 
brokers.
* QpidQueueStats: Collect and print queue statistics. This is a rewrite of the 
Python version and 
  illustrates the use of QuerySubscriptions (via the Console side emulation)to 
subscribe to 
  objects on the ManagementAgent.
* QueueFuse: QueueFuse provides protection to message producers from consumers 
who can't consume 
  messages fast enough. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
Apache Qpid - AMQP Messaging Implementation
Project:  http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org

[jira] [Updated] (QPID-3675) New Feature Announce - Java QMF2 API Implementation.

[Fraser Adams (Updated) (JIRA)]

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

Fraser Adams updated QPID-3675:
---

Attachment: qmf2.tar.gz

Java QMF2 API Implementation

> New Feature Announce - Java QMF2 API Implementation.
> 
>
> Key: QPID-3675
> URL: https://issues.apache.org/jira/browse/QPID-3675
> Project: Qpid
>  Issue Type: New Feature
>  Components: Java Management : QMF
>Affects Versions: 0.12
> Environment: Java QMF2
>Reporter: Fraser Adams
>  Labels: features
> Attachments: qmf2.tar.gz
>
>
> This is the first release of a QMF2 API Implementation for Java.
> Features:
> * Full Implementation of QMF2 Console, Agent and AgentExternal.
> * Supports QMF2 Query Subscriptions on Agent/AgentExternal implementations.
> * Emulates QMF2 Query Subscriptions on the Console side for the broker 
> ManagementAgent by
>   intercepting _data indications and filtering against QmfQuery. This is 
> necessary as the
>   ManagemetAgent doesn't yet support QMF2 style Query Subscriptions.
> * Console supports Agent discovery via findAgent() method, which can support 
> partial matches,
>   which is useful because the full Agent name has a UUID representing the 
> "instance" so it's hard
>   to know the full name.
> * QmfQuery supports regex matching.
> * Supports QMF2 WorkItem Event model and in addition supports an alternative 
> QmfEventListener 
>   Event model, which is rather more like the JMS MessageListener model.
> Example Tools Provided:
> * ConnectionAudit: Audits connections to one or more Qpid message brokers 
> against a whitelist.
> * ConnectionLogger: A QMF2 class used to provide information about 
> connections made to a broker.
> * QpidConfig: QpidConfig is a fairly "literal" Java port of the python 
> qpid-config tool. Uses pure 
>   QMF2 for adding/deleting queues, exchanges & bindings this provides useful 
> illustration of how 
>   to do these things using the ManagementAgent method calls.
> * QpidCtrl: A tool to allow QMF2 methods to be invoked from the command line.
> * QpidPrintEvents: Collect and print events from one or more Qpid message 
> brokers.
> * QpidQueueStats: Collect and print queue statistics. This is a rewrite of 
> the Python version and 
>   illustrates the use of QuerySubscriptions (via the Console side 
> emulation)to subscribe to 
>   objects on the ManagementAgent.
> * QueueFuse: QueueFuse provides protection to message producers from 
> consumers who can't consume 
>   messages fast enough. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
Apache Qpid - AMQP Messaging Implementation
Project:  http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org

[jira] [Assigned] (QPID-3675) New Feature Announce - Java QMF2 API Implementation.

[Ted Ross (Assigned) (JIRA)]

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

Ted Ross reassigned QPID-3675:
--

Assignee: Ted Ross

> New Feature Announce - Java QMF2 API Implementation.
> 
>
> Key: QPID-3675
> URL: https://issues.apache.org/jira/browse/QPID-3675
> Project: Qpid
>  Issue Type: New Feature
>  Components: Java Management : QMF
>Affects Versions: 0.12
> Environment: Java QMF2
>Reporter: Fraser Adams
>Assignee: Ted Ross
>  Labels: features
> Attachments: qmf2.tar.gz
>
>
> This is the first release of a QMF2 API Implementation for Java.
> Features:
> * Full Implementation of QMF2 Console, Agent and AgentExternal.
> * Supports QMF2 Query Subscriptions on Agent/AgentExternal implementations.
> * Emulates QMF2 Query Subscriptions on the Console side for the broker 
> ManagementAgent by
>   intercepting _data indications and filtering against QmfQuery. This is 
> necessary as the
>   ManagemetAgent doesn't yet support QMF2 style Query Subscriptions.
> * Console supports Agent discovery via findAgent() method, which can support 
> partial matches,
>   which is useful because the full Agent name has a UUID representing the 
> "instance" so it's hard
>   to know the full name.
> * QmfQuery supports regex matching.
> * Supports QMF2 WorkItem Event model and in addition supports an alternative 
> QmfEventListener 
>   Event model, which is rather more like the JMS MessageListener model.
> Example Tools Provided:
> * ConnectionAudit: Audits connections to one or more Qpid message brokers 
> against a whitelist.
> * ConnectionLogger: A QMF2 class used to provide information about 
> connections made to a broker.
> * QpidConfig: QpidConfig is a fairly "literal" Java port of the python 
> qpid-config tool. Uses pure 
>   QMF2 for adding/deleting queues, exchanges & bindings this provides useful 
> illustration of how 
>   to do these things using the ManagementAgent method calls.
> * QpidCtrl: A tool to allow QMF2 methods to be invoked from the command line.
> * QpidPrintEvents: Collect and print events from one or more Qpid message 
> brokers.
> * QpidQueueStats: Collect and print queue statistics. This is a rewrite of 
> the Python version and 
>   illustrates the use of QuerySubscriptions (via the Console side 
> emulation)to subscribe to 
>   objects on the ManagementAgent.
> * QueueFuse: QueueFuse provides protection to message producers from 
> consumers who can't consume 
>   messages fast enough. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
Apache Qpid - AMQP Messaging Implementation
Project:  http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org

[jira] [Commented] (QPID-3675) New Feature Announce - Java QMF2 API Implementation.

[Fraser Adams (JIRA)]

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

Fraser Adams commented on QPID-3675:


I've just made a fairly major uplift to the QMF2 code base.

There are a few bug fixes to the core QMF2 implementation, the most significant 
being that the ManagementAgent can return multiple partial responses if there 
are large numbers of objects the QMF2 getObjects() call now caters for that.

However the most significant uplift is the addition of:
1) A QMF2 REST API Implementation.
2) A JavaScript QMF2 Implementation that uses the REST API as a back end.
3) A fully featured Qpid Management Web GUI that does pretty much anything 
you'd need to do to
monitor and manage one or more brokers (it supports connecting to different 
brokers)

The Web GUI works on multiple browsers and is even functional on IE6, it morphs 
quite well onto mobile devices and uses GPU accelerated animations to give a 
fairly "native app" feel on iPad/iPhone.

The REST API Server was deliberately designed to have almost no dependencies. 
It uses the com.sun.net.httpserver.HttpServer embedded Web Server that is part 
of JDK 6 (at least on Sun and OpenJDK) so just requires the Qpid jars on the 
classpath. It has been designed to make it fairly easy to add a Servlet 
implementation, but that's not been done yet as the initial goal was to make it 
fairly dependency free and embedded.


To get up and running all that should be required is the Qpid jars on the 
classpath and running ant in the root qmf2 directory.


Once compiled cd to bin and do ./QpidRestAPI.sh by default it tries to bind to 
the 
wildcard address on the host it's running on and port 8080 though this stuff is 
configurable.

Point a browser at :8080 and you should be in business. By default it 
will create a default QMF connection to a broker running on the same host as 
the QpidRestAPI on port 5672 but the default broker connection is configurable 
too.

Once running you can add QMF2 Console Connections to other brokers and connect 
to them via the Web GUI.

The main limitation at the moment is the authentication. It uses basic 
authentication so username/password are sent clear. I'll look to do something 
better IDC but I wanted to get it released as it represents around a years 
worth of work over weekends.

It's all released under the Apache Licence and the GUI uses a UI library that I 
ended up writing as part of this project which should be reusable.

I hope that this is useful to people, as I say it's taken an awful lot of 
effort to put together so I'd really appreciate feedback.

I'll attach the updated zip and some screenshots.






> New Feature Announce - Java QMF2 API Implementation.
> 
>
> Key: QPID-3675
> URL: https://issues.apache.org/jira/browse/QPID-3675
> Project: Qpid
>  Issue Type: New Feature
>  Components: Qpid Managment Framework
>Affects Versions: 0.12
> Environment: Java QMF2
>Reporter: Fraser Adams
>    Assignee: Ted Ross
>  Labels: features
>     Attachments: ipod bindings.png, qmf2.tar.gz, qmf2.tar.gz
>
>
> This is the first release of a QMF2 API Implementation for Java.
> Features:
> * Full Implementation of QMF2 Console, Agent and AgentExternal.
> * Supports QMF2 Query Subscriptions on Agent/AgentExternal implementations.
> * Emulates QMF2 Query Subscriptions on the Console side for the broker 
> ManagementAgent by
>   intercepting _data indications and filtering against QmfQuery. This is 
> necessary as the
>   ManagemetAgent doesn't yet support QMF2 style Query Subscriptions.
> * Console supports Agent discovery via findAgent() method, which can support 
> partial matches,
>   which is useful because the full Agent name has a UUID representing the 
> "instance" so it's hard
>   to know the full name.
> * QmfQuery supports regex matching.
> * Supports QMF2 WorkItem Event model and in addition supports an alternative 
> QmfEventListener 
>   Event model, which is rather more like the JMS MessageListener model.
> Example Tools Provided:
> * ConnectionAudit: Audits connections to one or more Qpid message brokers 
> against a whitelist.
> * ConnectionLogger: A QMF2 class used to provide information about 
> connections made to a broker.
> * QpidConfig: QpidConfig is a fairly "literal" Java port of the python 
> qpid-config tool. Uses pure 
>   QMF2 for adding/deleting queues, exchanges & bindings this provides useful 
> illustration of how 
>   to do these things using the ManagementAgent method call

[jira] [Updated] (QPID-3675) New Feature Announce - Java QMF2 API Implementation.

[Fraser Adams (JIRA)]

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

Fraser Adams updated QPID-3675:
---

Attachment: ipod bindings.png
qmf2.tar.gz

> New Feature Announce - Java QMF2 API Implementation.
> 
>
> Key: QPID-3675
> URL: https://issues.apache.org/jira/browse/QPID-3675
> Project: Qpid
>  Issue Type: New Feature
>  Components: Qpid Managment Framework
>Affects Versions: 0.12
> Environment: Java QMF2
>Reporter: Fraser Adams
>Assignee: Ted Ross
>  Labels: features
>     Attachments: ipod bindings.png, qmf2.tar.gz, qmf2.tar.gz
>
>
> This is the first release of a QMF2 API Implementation for Java.
> Features:
> * Full Implementation of QMF2 Console, Agent and AgentExternal.
> * Supports QMF2 Query Subscriptions on Agent/AgentExternal implementations.
> * Emulates QMF2 Query Subscriptions on the Console side for the broker 
> ManagementAgent by
>   intercepting _data indications and filtering against QmfQuery. This is 
> necessary as the
>   ManagemetAgent doesn't yet support QMF2 style Query Subscriptions.
> * Console supports Agent discovery via findAgent() method, which can support 
> partial matches,
>   which is useful because the full Agent name has a UUID representing the 
> "instance" so it's hard
>   to know the full name.
> * QmfQuery supports regex matching.
> * Supports QMF2 WorkItem Event model and in addition supports an alternative 
> QmfEventListener 
>   Event model, which is rather more like the JMS MessageListener model.
> Example Tools Provided:
> * ConnectionAudit: Audits connections to one or more Qpid message brokers 
> against a whitelist.
> * ConnectionLogger: A QMF2 class used to provide information about 
> connections made to a broker.
> * QpidConfig: QpidConfig is a fairly "literal" Java port of the python 
> qpid-config tool. Uses pure 
>   QMF2 for adding/deleting queues, exchanges & bindings this provides useful 
> illustration of how 
>   to do these things using the ManagementAgent method calls.
> * QpidCtrl: A tool to allow QMF2 methods to be invoked from the command line.
> * QpidPrintEvents: Collect and print events from one or more Qpid message 
> brokers.
> * QpidQueueStats: Collect and print queue statistics. This is a rewrite of 
> the Python version and 
>   illustrates the use of QuerySubscriptions (via the Console side 
> emulation)to subscribe to 
>   objects on the ManagementAgent.
> * QueueFuse: QueueFuse provides protection to message producers from 
> consumers who can't consume 
>   messages fast enough. 

--
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

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Updated] (QPID-3675) New Feature Announce - Java QMF2 API Implementation.

[Fraser Adams (JIRA)]

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

Fraser Adams updated QPID-3675:
---

Attachment: Firefox Graphs.png
IE8 Add Queue.png

> New Feature Announce - Java QMF2 API Implementation.
> 
>
> Key: QPID-3675
> URL: https://issues.apache.org/jira/browse/QPID-3675
> Project: Qpid
>  Issue Type: New Feature
>  Components: Qpid Managment Framework
>Affects Versions: 0.12
> Environment: Java QMF2
>Reporter: Fraser Adams
>Assignee: Ted Ross
>  Labels: features
> Attachments: Firefox Graphs.png, IE8 Add Queue.png, ipod 
> bindings.png, qmf2.tar.gz, qmf2.tar.gz
>
>
> This is the first release of a QMF2 API Implementation for Java.
> Features:
> * Full Implementation of QMF2 Console, Agent and AgentExternal.
> * Supports QMF2 Query Subscriptions on Agent/AgentExternal implementations.
> * Emulates QMF2 Query Subscriptions on the Console side for the broker 
> ManagementAgent by
>   intercepting _data indications and filtering against QmfQuery. This is 
> necessary as the
>   ManagemetAgent doesn't yet support QMF2 style Query Subscriptions.
> * Console supports Agent discovery via findAgent() method, which can support 
> partial matches,
>   which is useful because the full Agent name has a UUID representing the 
> "instance" so it's hard
>   to know the full name.
> * QmfQuery supports regex matching.
> * Supports QMF2 WorkItem Event model and in addition supports an alternative 
> QmfEventListener 
>   Event model, which is rather more like the JMS MessageListener model.
> Example Tools Provided:
> * ConnectionAudit: Audits connections to one or more Qpid message brokers 
> against a whitelist.
> * ConnectionLogger: A QMF2 class used to provide information about 
> connections made to a broker.
> * QpidConfig: QpidConfig is a fairly "literal" Java port of the python 
> qpid-config tool. Uses pure 
>   QMF2 for adding/deleting queues, exchanges & bindings this provides useful 
> illustration of how 
>   to do these things using the ManagementAgent method calls.
> * QpidCtrl: A tool to allow QMF2 methods to be invoked from the command line.
> * QpidPrintEvents: Collect and print events from one or more Qpid message 
> brokers.
> * QpidQueueStats: Collect and print queue statistics. This is a rewrite of 
> the Python version and 
>   illustrates the use of QuerySubscriptions (via the Console side 
> emulation)to subscribe to 
>   objects on the ManagementAgent.
> * QueueFuse: QueueFuse provides protection to message producers from 
> consumers who can't consume 
>   messages fast enough. 

--
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

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (QPID-3675) New Feature Announce - Java QMF2 API Implementation.

[Fraser Adams (JIRA)]

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

Fraser Adams commented on QPID-3675:


Just for clarity the update is the 501K qmf2.tar.gz dated 20th Jan 2013, should 
probably have given it a different name.

Also to confirm it's all released under the Apache 2.0 licence, I'm not sure if 
I was meant to tick something when I did the file upload to confirm this? But 
it *IS* all Apache 2.0

> New Feature Announce - Java QMF2 API Implementation.
> 
>
> Key: QPID-3675
> URL: https://issues.apache.org/jira/browse/QPID-3675
> Project: Qpid
>  Issue Type: New Feature
>  Components: Qpid Managment Framework
>Affects Versions: 0.12
> Environment: Java QMF2
>Reporter: Fraser Adams
>Assignee: Ted Ross
>  Labels: features
> Attachments: Firefox Graphs.png, IE8 Add Queue.png, ipod 
> bindings.png, qmf2.tar.gz, qmf2.tar.gz
>
>
> This is the first release of a QMF2 API Implementation for Java.
> Features:
> * Full Implementation of QMF2 Console, Agent and AgentExternal.
> * Supports QMF2 Query Subscriptions on Agent/AgentExternal implementations.
> * Emulates QMF2 Query Subscriptions on the Console side for the broker 
> ManagementAgent by
>   intercepting _data indications and filtering against QmfQuery. This is 
> necessary as the
>   ManagemetAgent doesn't yet support QMF2 style Query Subscriptions.
> * Console supports Agent discovery via findAgent() method, which can support 
> partial matches,
>   which is useful because the full Agent name has a UUID representing the 
> "instance" so it's hard
>   to know the full name.
> * QmfQuery supports regex matching.
> * Supports QMF2 WorkItem Event model and in addition supports an alternative 
> QmfEventListener 
>   Event model, which is rather more like the JMS MessageListener model.
> Example Tools Provided:
> * ConnectionAudit: Audits connections to one or more Qpid message brokers 
> against a whitelist.
> * ConnectionLogger: A QMF2 class used to provide information about 
> connections made to a broker.
> * QpidConfig: QpidConfig is a fairly "literal" Java port of the python 
> qpid-config tool. Uses pure 
>   QMF2 for adding/deleting queues, exchanges & bindings this provides useful 
> illustration of how 
>   to do these things using the ManagementAgent method calls.
> * QpidCtrl: A tool to allow QMF2 methods to be invoked from the command line.
> * QpidPrintEvents: Collect and print events from one or more Qpid message 
> brokers.
> * QpidQueueStats: Collect and print queue statistics. This is a rewrite of 
> the Python version and 
>   illustrates the use of QuerySubscriptions (via the Console side 
> emulation)to subscribe to 
>   objects on the ManagementAgent.
> * QueueFuse: QueueFuse provides protection to message producers from 
> consumers who can't consume 
>   messages fast enough. 

--
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

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Updated] (QPID-3675) New Feature Announce - Java QMF2 API Implementation.

[Fraser Adams (JIRA)]

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

Fraser Adams updated QPID-3675:
---

Attachment: qmf2-v1.1.tar.gz

Latest update of the QMF2 library.
Contains fixes to cope with the changes made to how amqp/list is exposed to JMS 
in Qpid 0.20.

Now allows disabling QMF2 Events. When this happens timed polling rather than 
AJAX long-polling is used for updating. This might help in cases where a 
browser only supports a small number of connections.

> New Feature Announce - Java QMF2 API Implementation.
> 
>
> Key: QPID-3675
> URL: https://issues.apache.org/jira/browse/QPID-3675
> Project: Qpid
>  Issue Type: New Feature
>  Components: Qpid Managment Framework
>Affects Versions: 0.12
> Environment: Java QMF2
>Reporter: Fraser Adams
>Assignee: Ted Ross
>  Labels: features
> Attachments: Firefox Graphs.png, IE8 Add Queue.png, ipod 
> bindings.png, qmf2.tar.gz, qmf2.tar.gz, qmf2-v1.1.tar.gz
>
>
> This is the first release of a QMF2 API Implementation for Java.
> Features:
> * Full Implementation of QMF2 Console, Agent and AgentExternal.
> * Supports QMF2 Query Subscriptions on Agent/AgentExternal implementations.
> * Emulates QMF2 Query Subscriptions on the Console side for the broker 
> ManagementAgent by
>   intercepting _data indications and filtering against QmfQuery. This is 
> necessary as the
>   ManagemetAgent doesn't yet support QMF2 style Query Subscriptions.
> * Console supports Agent discovery via findAgent() method, which can support 
> partial matches,
>   which is useful because the full Agent name has a UUID representing the 
> "instance" so it's hard
>   to know the full name.
> * QmfQuery supports regex matching.
> * Supports QMF2 WorkItem Event model and in addition supports an alternative 
> QmfEventListener 
>   Event model, which is rather more like the JMS MessageListener model.
> Example Tools Provided:
> * ConnectionAudit: Audits connections to one or more Qpid message brokers 
> against a whitelist.
> * ConnectionLogger: A QMF2 class used to provide information about 
> connections made to a broker.
> * QpidConfig: QpidConfig is a fairly "literal" Java port of the python 
> qpid-config tool. Uses pure 
>   QMF2 for adding/deleting queues, exchanges & bindings this provides useful 
> illustration of how 
>   to do these things using the ManagementAgent method calls.
> * QpidCtrl: A tool to allow QMF2 methods to be invoked from the command line.
> * QpidPrintEvents: Collect and print events from one or more Qpid message 
> brokers.
> * QpidQueueStats: Collect and print queue statistics. This is a rewrite of 
> the Python version and 
>   illustrates the use of QuerySubscriptions (via the Console side 
> emulation)to subscribe to 
>   objects on the ManagementAgent.
> * QueueFuse: QueueFuse provides protection to message producers from 
> consumers who can't consume 
>   messages fast enough. 

--
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

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Updated] (QPID-3675) New Feature Announce - Java QMF2 API Implementation.

[Fraser Adams (JIRA)]

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

Fraser Adams updated QPID-3675:
---

Attachment: qmf2-v1.2.tar.gz

QMF2 & Qpid GUI Release 1.2

New Features:

* Initial set of QMF Console Connections is now configurable via the file
  qpid-web/web/ui/config.js
* Renders new Broker/Queue properties made available in Qpid 0.20 and allows
  the less frequently used ones to be hidden to avoid too much extra clutter.

Bug Fixes:

* Greatly improved reliability when selecting between different Connections.
  Previously there was occasional glitching when selecting a new Connection 
which
  caused it to hang on Broker Disconnected. It could be resolved by selecting 
  another Connection and selecting back, but this fix makes it generally better.
* Fixed "null pointer" bug that sometimes occurred when navigating to msgDepth
  graph - thanks to Sergey Zhemzhitsky for that!
* Fixed "null pointer" bug in Authenticator which caused a fairly unfriendly
  failure if a username was supplied that wasn't in the 
authentication.properties -
  thanks to Bruno Matos for that!
* Default to anonymous rather than guest if no username is supplied in 
Connection URL,
  this explicitly sets sasl_mechs:"ANONYMOUS" in the Java ConnectionURL for 
this case.
* For some but not all instances of IE8 the popup window "smoked glass" 
semi-transparent
  background got rendered with a weird gradient??!! After some Googling I 
believe
  that this was due to the 1x1 png image being used. I've replaced this with an 
8x8
  image which apparently resolves this. I couldn't reproduce this on my XP or 
Win7
  IE8 VMs so I can't say for certain that this problem is definitely fixed..

> New Feature Announce - Java QMF2 API Implementation.
> 
>
> Key: QPID-3675
> URL: https://issues.apache.org/jira/browse/QPID-3675
> Project: Qpid
>  Issue Type: New Feature
>  Components: Qpid Managment Framework
>Affects Versions: 0.12
> Environment: Java QMF2
>Reporter: Fraser Adams
>Assignee: Ted Ross
>  Labels: features
>     Attachments: Firefox Graphs.png, IE8 Add Queue.png, ipod 
> bindings.png, qmf2.tar.gz, qmf2.tar.gz, qmf2-v1.1.tar.gz, qmf2-v1.2.tar.gz
>
>
> This is the first release of a QMF2 API Implementation for Java.
> Features:
> * Full Implementation of QMF2 Console, Agent and AgentExternal.
> * Supports QMF2 Query Subscriptions on Agent/AgentExternal implementations.
> * Emulates QMF2 Query Subscriptions on the Console side for the broker 
> ManagementAgent by
>   intercepting _data indications and filtering against QmfQuery. This is 
> necessary as the
>   ManagemetAgent doesn't yet support QMF2 style Query Subscriptions.
> * Console supports Agent discovery via findAgent() method, which can support 
> partial matches,
>   which is useful because the full Agent name has a UUID representing the 
> "instance" so it's hard
>   to know the full name.
> * QmfQuery supports regex matching.
> * Supports QMF2 WorkItem Event model and in addition supports an alternative 
> QmfEventListener 
>   Event model, which is rather more like the JMS MessageListener model.
> Example Tools Provided:
> * ConnectionAudit: Audits connections to one or more Qpid message brokers 
> against a whitelist.
> * ConnectionLogger: A QMF2 class used to provide information about 
> connections made to a broker.
> * QpidConfig: QpidConfig is a fairly "literal" Java port of the python 
> qpid-config tool. Uses pure 
>   QMF2 for adding/deleting queues, exchanges & bindings this provides useful 
> illustration of how 
>   to do these things using the ManagementAgent method calls.
> * QpidCtrl: A tool to allow QMF2 methods to be invoked from the command line.
> * QpidPrintEvents: Collect and print events from one or more Qpid message 
> brokers.
> * QpidQueueStats: Collect and print queue statistics. This is a rewrite of 
> the Python version and 
>   illustrates the use of QuerySubscriptions (via the Console side 
> emulation)to subscribe to 
>   objects on the ManagementAgent.
> * QueueFuse: QueueFuse provides protection to message producers from 
> consumers who can't consume 
>   messages fast enough. 

--
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

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Updated] (QPID-3675) New Feature Announce - Java QMF2 API Implementation.

[Fraser Adams (JIRA)]

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

Fraser Adams updated QPID-3675:
---

Attachment: qmf2-v1.3.tar.gz

QMF2 & Qpid GUI Release 1.3

New Features:

* Implemented QMF2 support for the Java Broker via the ManagementFactory and 
ManagementPlugin interfaces with QMF
  Management Objects backed by the recent org.apache.qpid.server.model.* 
classes. Tested on Qpid 0.20 your mileage
  may vary on earlier version of the Java Broker.
* Fairly complete support for the main QMF management-schema.xml within the 
current constraints of the  
  org.apache.qpid.server.model.* classes.
* Support for create/delete of exchange, queue, bindings.
* Works with recent (QMF2 based) qpid-config.
* Virtual Hosts are supported. In order to remain compatible with qpid-config 
I've adopted a convention
  [vhost:/], [vhost:/]
  in other words with the default Virtual Host the Virtual Host name is 
"hidden" but for other Virtual Hosts
  exchanges/queues are prefixed with "vhost:/". So for example:
  qpid-config add queue vhost:development/test
  would add a queue called "test" to the Virtual Host called "development".
* QMF Events are created e.g. clientConnect, clientDisconnect, queueDeclare, 
queueDelete etc. though some properties
  aren't fully populated due to current limitations of 
org.apache.qpid.server.model.* classes.
* QMF2 GUI supports Java Broker though it could do with some tweaks to improve 
presentation for multiple Virtual Hosts.

Limitations:
* There are quite a few differences between the C++ and Java Brokers 
particularly with respect to Queues. It
  would be good to add extra features to the org.apache.qpid.server.model.* 
classes to bridge some of the gaps.
* The QMF GUI could do with allowing some of the extra features of the Java 
Broker so a bit of thought is going
  to be needed to present this in the most consistent manner.

Note that this is an initial release. It could definitely do with more soak 
testing so if you use this on an
operational Broker be aware of this. It's looking pretty good but I can't 
guarantee that there won't be quirks.


Look at README-java-Broker but in precis:

ant broker-plugin

N.B. this requires that the Qpid jars (preferably qpid-all.jar) are on your 
CLASSPATH and that the
QPID_HOME environment variable is set to point to /java/build (QPID_HOME 
is needed by the Java 
broker anyway).

> New Feature Announce - Java QMF2 API Implementation.
> 
>
> Key: QPID-3675
> URL: https://issues.apache.org/jira/browse/QPID-3675
> Project: Qpid
>  Issue Type: New Feature
>  Components: Qpid Managment Framework
>Affects Versions: 0.12
> Environment: Java QMF2
>Reporter: Fraser Adams
>Assignee: Ted Ross
>      Labels: features
>     Attachments: Firefox Graphs.png, IE8 Add Queue.png, ipod 
> bindings.png, qmf2.tar.gz, qmf2.tar.gz, qmf2-v1.1.tar.gz, qmf2-v1.2.tar.gz, 
> qmf2-v1.3.tar.gz
>
>
> This is the first release of a QMF2 API Implementation for Java.
> Features:
> * Full Implementation of QMF2 Console, Agent and AgentExternal.
> * Supports QMF2 Query Subscriptions on Agent/AgentExternal implementations.
> * Emulates QMF2 Query Subscriptions on the Console side for the broker 
> ManagementAgent by
>   intercepting _data indications and filtering against QmfQuery. This is 
> necessary as the
>   ManagemetAgent doesn't yet support QMF2 style Query Subscriptions.
> * Console supports Agent discovery via findAgent() method, which can support 
> partial matches,
>   which is useful because the full Agent name has a UUID representing the 
> "instance" so it's hard
>   to know the full name.
> * QmfQuery supports regex matching.
> * Supports QMF2 WorkItem Event model and in addition supports an alternative 
> QmfEventListener 
>   Event model, which is rather more like the JMS MessageListener model.
> Example Tools Provided:
> * ConnectionAudit: Audits connections to one or more Qpid message brokers 
> against a whitelist.
> * ConnectionLogger: A QMF2 class used to provide information about 
> connections made to a broker.
> * QpidConfig: QpidConfig is a fairly "literal" Java port of the python 
> qpid-config tool. Uses pure 
>   QMF2 for adding/deleting queues, exchanges & bindings this provides useful 
> illustration of how 
>   to do these things using the ManagementAgent method calls.
> * QpidCtrl: A tool to allow QMF2 methods to be invoked from the command line.
> * QpidPrintEvents: Collect and print events from one or more Qpid message 
> brokers.
&

[jira] [Commented] (QPID-3675) New Feature Announce - Java QMF2 API Implementation.

[Fraser Adams (JIRA)]

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

Fraser Adams commented on QPID-3675:


This work has now been added to the main Qpid code base in:
/tools/src/java


The Java Broker QmfManagementPlugin work described in release 1.3 above had to 
be rewritten following changes to the Java Broker Plugin API between Qpid 0.20 
and Qpid 0.22 the committed QmfManagementPlugin works with Qpid 0.22 upwards, 
if you want to use with Qpid 0.20 you would need to use the release 1.3 tarball.

> New Feature Announce - Java QMF2 API Implementation.
> 
>
> Key: QPID-3675
> URL: https://issues.apache.org/jira/browse/QPID-3675
> Project: Qpid
>  Issue Type: New Feature
>  Components: Qpid Managment Framework
>Affects Versions: 0.12
> Environment: Java QMF2
>Reporter: Fraser Adams
>Assignee: Ted Ross
>  Labels: features
> Attachments: Firefox Graphs.png, IE8 Add Queue.png, ipod 
> bindings.png, qmf2.tar.gz, qmf2.tar.gz, qmf2-v1.1.tar.gz, qmf2-v1.2.tar.gz, 
> qmf2-v1.3.tar.gz
>
>
> This is the first release of a QMF2 API Implementation for Java.
> Features:
> * Full Implementation of QMF2 Console, Agent and AgentExternal.
> * Supports QMF2 Query Subscriptions on Agent/AgentExternal implementations.
> * Emulates QMF2 Query Subscriptions on the Console side for the broker 
> ManagementAgent by
>   intercepting _data indications and filtering against QmfQuery. This is 
> necessary as the
>   ManagemetAgent doesn't yet support QMF2 style Query Subscriptions.
> * Console supports Agent discovery via findAgent() method, which can support 
> partial matches,
>   which is useful because the full Agent name has a UUID representing the 
> "instance" so it's hard
>   to know the full name.
> * QmfQuery supports regex matching.
> * Supports QMF2 WorkItem Event model and in addition supports an alternative 
> QmfEventListener 
>   Event model, which is rather more like the JMS MessageListener model.
> Example Tools Provided:
> * ConnectionAudit: Audits connections to one or more Qpid message brokers 
> against a whitelist.
> * ConnectionLogger: A QMF2 class used to provide information about 
> connections made to a broker.
> * QpidConfig: QpidConfig is a fairly "literal" Java port of the python 
> qpid-config tool. Uses pure 
>   QMF2 for adding/deleting queues, exchanges & bindings this provides useful 
> illustration of how 
>   to do these things using the ManagementAgent method calls.
> * QpidCtrl: A tool to allow QMF2 methods to be invoked from the command line.
> * QpidPrintEvents: Collect and print events from one or more Qpid message 
> brokers.
> * QpidQueueStats: Collect and print queue statistics. This is a rewrite of 
> the Python version and 
>   illustrates the use of QuerySubscriptions (via the Console side 
> emulation)to subscribe to 
>   objects on the ManagementAgent.
> * QueueFuse: QueueFuse provides protection to message producers from 
> consumers who can't consume 
>   messages fast enough. 

--
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

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Resolved] (QPID-3675) New Feature Announce - Java QMF2 API Implementation.

[Fraser Adams (JIRA)]

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

Fraser Adams resolved QPID-3675.


Resolution: Fixed

Committed to repository

/tools/src/java

r1465662

> New Feature Announce - Java QMF2 API Implementation.
> 
>
> Key: QPID-3675
> URL: https://issues.apache.org/jira/browse/QPID-3675
> Project: Qpid
>  Issue Type: New Feature
>  Components: Qpid Managment Framework
>Affects Versions: 0.12
> Environment: Java QMF2
>Reporter: Fraser Adams
>Assignee: Ted Ross
>  Labels: features
> Attachments: Firefox Graphs.png, IE8 Add Queue.png, ipod 
> bindings.png, qmf2.tar.gz, qmf2.tar.gz, qmf2-v1.1.tar.gz, qmf2-v1.2.tar.gz, 
> qmf2-v1.3.tar.gz
>
>
> This is the first release of a QMF2 API Implementation for Java.
> Features:
> * Full Implementation of QMF2 Console, Agent and AgentExternal.
> * Supports QMF2 Query Subscriptions on Agent/AgentExternal implementations.
> * Emulates QMF2 Query Subscriptions on the Console side for the broker 
> ManagementAgent by
>   intercepting _data indications and filtering against QmfQuery. This is 
> necessary as the
>   ManagemetAgent doesn't yet support QMF2 style Query Subscriptions.
> * Console supports Agent discovery via findAgent() method, which can support 
> partial matches,
>   which is useful because the full Agent name has a UUID representing the 
> "instance" so it's hard
>   to know the full name.
> * QmfQuery supports regex matching.
> * Supports QMF2 WorkItem Event model and in addition supports an alternative 
> QmfEventListener 
>   Event model, which is rather more like the JMS MessageListener model.
> Example Tools Provided:
> * ConnectionAudit: Audits connections to one or more Qpid message brokers 
> against a whitelist.
> * ConnectionLogger: A QMF2 class used to provide information about 
> connections made to a broker.
> * QpidConfig: QpidConfig is a fairly "literal" Java port of the python 
> qpid-config tool. Uses pure 
>   QMF2 for adding/deleting queues, exchanges & bindings this provides useful 
> illustration of how 
>   to do these things using the ManagementAgent method calls.
> * QpidCtrl: A tool to allow QMF2 methods to be invoked from the command line.
> * QpidPrintEvents: Collect and print events from one or more Qpid message 
> brokers.
> * QpidQueueStats: Collect and print queue statistics. This is a rewrite of 
> the Python version and 
>   illustrates the use of QuerySubscriptions (via the Console side 
> emulation)to subscribe to 
>   objects on the ManagementAgent.
> * QueueFuse: QueueFuse provides protection to message producers from 
> consumers who can't consume 
>   messages fast enough. 

--
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

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Created] (QPID-6024) Changes tp Java Broker Model affected QMF2 plugin

[Fraser Adams (JIRA)]

Fraser Adams created QPID-6024:
--

 Summary: Changes tp Java Broker Model affected QMF2 plugin
 Key: QPID-6024
 URL: https://issues.apache.org/jira/browse/QPID-6024
 Project: Qpid
  Issue Type: Bug
Reporter: Fraser Adams
Priority: Blocker


A recent change to the Java Broker Model Port class changed an accessor method 
name from getAvailableProtocols to getProtocols, this change caused the QMF2 
plugin to stop compiling agentdata/Broker.java.

agentdata/Broker.java needs updating to reflect change to getProtocols



--
This message was sent by Atlassian JIRA
(v6.2#6252)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (QPID-6024) Changes tp Java Broker Model affected QMF2 plugin

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on QPID-6024:
---

Commit 1619137 from [~fadams] in branch 'qpid/trunk'
[ https://svn.apache.org/r1619137 ]

QPID-6024: Update agentdata/Broker.java to reflect change in Java Broker Model 
Port class that changed getAvailableProtocols to getProtocols

> Changes tp Java Broker Model affected QMF2 plugin
> -
>
> Key: QPID-6024
> URL: https://issues.apache.org/jira/browse/QPID-6024
> Project: Qpid
>  Issue Type: Bug
>Reporter: Fraser Adams
>Priority: Blocker
>
> A recent change to the Java Broker Model Port class changed an accessor 
> method name from getAvailableProtocols to getProtocols, this change caused 
> the QMF2 plugin to stop compiling agentdata/Broker.java.
> agentdata/Broker.java needs updating to reflect change to getProtocols



--
This message was sent by Atlassian JIRA
(v6.2#6252)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Resolved] (QPID-6024) Changes tp Java Broker Model affected QMF2 plugin

[Fraser Adams (JIRA)]

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

Fraser Adams resolved QPID-6024.


Resolution: Fixed

> Changes tp Java Broker Model affected QMF2 plugin
> -
>
> Key: QPID-6024
> URL: https://issues.apache.org/jira/browse/QPID-6024
> Project: Qpid
>  Issue Type: Bug
>Reporter: Fraser Adams
>Priority: Blocker
>
> A recent change to the Java Broker Model Port class changed an accessor 
> method name from getAvailableProtocols to getProtocols, this change caused 
> the QMF2 plugin to stop compiling agentdata/Broker.java.
> agentdata/Broker.java needs updating to reflect change to getProtocols



--
This message was sent by Atlassian JIRA
(v6.2#6252)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Closed] (QPID-6024) Changes tp Java Broker Model affected QMF2 plugin

[Fraser Adams (JIRA)]

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

Fraser Adams closed QPID-6024.
--


> Changes tp Java Broker Model affected QMF2 plugin
> -
>
> Key: QPID-6024
> URL: https://issues.apache.org/jira/browse/QPID-6024
> Project: Qpid
>  Issue Type: Bug
>Reporter: Fraser Adams
>Priority: Blocker
>
> A recent change to the Java Broker Model Port class changed an accessor 
> method name from getAvailableProtocols to getProtocols, this change caused 
> the QMF2 plugin to stop compiling agentdata/Broker.java.
> agentdata/Broker.java needs updating to reflect change to getProtocols



--
This message was sent by Atlassian JIRA
(v6.2#6252)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (QPID-6024) Changes tp Java Broker Model affected QMF2 plugin

[Robbie Gemmell (JIRA)]

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

Robbie Gemmell commented on QPID-6024:
--

Added fix-for (cant really be a blocker otherwise hehe)

> Changes tp Java Broker Model affected QMF2 plugin
> -
>
> Key: QPID-6024
> URL: https://issues.apache.org/jira/browse/QPID-6024
> Project: Qpid
>  Issue Type: Bug
>Reporter: Fraser Adams
>Priority: Blocker
> Fix For: 0.31
>
>
> A recent change to the Java Broker Model Port class changed an accessor 
> method name from getAvailableProtocols to getProtocols, this change caused 
> the QMF2 plugin to stop compiling agentdata/Broker.java.
> agentdata/Broker.java needs updating to reflect change to getProtocols



--
This message was sent by Atlassian JIRA
(v6.2#6252)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Updated] (QPID-6024) Changes tp Java Broker Model affected QMF2 plugin

[Robbie Gemmell (JIRA)]

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

Robbie Gemmell updated QPID-6024:
-

Fix Version/s: 0.31

> Changes tp Java Broker Model affected QMF2 plugin
> -
>
> Key: QPID-6024
> URL: https://issues.apache.org/jira/browse/QPID-6024
> Project: Qpid
>  Issue Type: Bug
>Reporter: Fraser Adams
>Priority: Blocker
> Fix For: 0.31
>
>
> A recent change to the Java Broker Model Port class changed an accessor 
> method name from getAvailableProtocols to getProtocols, this change caused 
> the QMF2 plugin to stop compiling agentdata/Broker.java.
> agentdata/Broker.java needs updating to reflect change to getProtocols



--
This message was sent by Atlassian JIRA
(v6.2#6252)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Assigned] (QPID-6024) Changes tp Java Broker Model affected QMF2 plugin

[Robbie Gemmell (JIRA)]

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

Robbie Gemmell reassigned QPID-6024:


Assignee: Fraser Adams

> Changes tp Java Broker Model affected QMF2 plugin
> -
>
> Key: QPID-6024
> URL: https://issues.apache.org/jira/browse/QPID-6024
> Project: Qpid
>  Issue Type: Bug
>Reporter: Fraser Adams
>Assignee: Fraser Adams
>Priority: Blocker
> Fix For: 0.31
>
>
> A recent change to the Java Broker Model Port class changed an accessor 
> method name from getAvailableProtocols to getProtocols, this change caused 
> the QMF2 plugin to stop compiling agentdata/Broker.java.
> agentdata/Broker.java needs updating to reflect change to getProtocols



--
This message was sent by Atlassian JIRA
(v6.2#6252)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Updated] (QPID-6024) Changes to Java Broker Model affected QMF2 plugin

[Robbie Gemmell (JIRA)]

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

Robbie Gemmell updated QPID-6024:
-

Summary: Changes to Java Broker Model affected QMF2 plugin  (was: Changes 
tp Java Broker Model affected QMF2 plugin)

> Changes to Java Broker Model affected QMF2 plugin
> -
>
> Key: QPID-6024
> URL: https://issues.apache.org/jira/browse/QPID-6024
> Project: Qpid
>  Issue Type: Bug
>Reporter: Fraser Adams
>Assignee: Fraser Adams
>Priority: Blocker
> Fix For: 0.31
>
>
> A recent change to the Java Broker Model Port class changed an accessor 
> method name from getAvailableProtocols to getProtocols, this change caused 
> the QMF2 plugin to stop compiling agentdata/Broker.java.
> agentdata/Broker.java needs updating to reflect change to getProtocols



--
This message was sent by Atlassian JIRA
(v6.2#6252)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (QPID-6024) Changes to Java Broker Model affected QMF2 plugin

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on QPID-6024:
---

Commit 1620361 from [~godfrer] in branch 'qpid/branches/0.30'
[ https://svn.apache.org/r1620361 ]

Merge r1619137 from trunk to address QPID-6024

> Changes to Java Broker Model affected QMF2 plugin
> -
>
> Key: QPID-6024
> URL: https://issues.apache.org/jira/browse/QPID-6024
> Project: Qpid
>  Issue Type: Bug
>Reporter: Fraser Adams
>Assignee: Fraser Adams
>Priority: Blocker
> Fix For: 0.31
>
>
> A recent change to the Java Broker Model Port class changed an accessor 
> method name from getAvailableProtocols to getProtocols, this change caused 
> the QMF2 plugin to stop compiling agentdata/Broker.java.
> agentdata/Broker.java needs updating to reflect change to getProtocols



--
This message was sent by Atlassian JIRA
(v6.2#6252)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Updated] (QPID-6024) Changes to Java Broker Model affected QMF2 plugin

[Rob Godfrey (JIRA)]

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

Rob Godfrey updated QPID-6024:
--

Fix Version/s: (was: 0.31)
   0.30

> Changes to Java Broker Model affected QMF2 plugin
> -
>
> Key: QPID-6024
> URL: https://issues.apache.org/jira/browse/QPID-6024
> Project: Qpid
>  Issue Type: Bug
>Reporter: Fraser Adams
>Assignee: Fraser Adams
>Priority: Blocker
> Fix For: 0.30
>
>
> A recent change to the Java Broker Model Port class changed an accessor 
> method name from getAvailableProtocols to getProtocols, this change caused 
> the QMF2 plugin to stop compiling agentdata/Broker.java.
> agentdata/Broker.java needs updating to reflect change to getProtocols



--
This message was sent by Atlassian JIRA
(v6.2#6252)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

Problems building trunk cpp broker since this morning - `src/qmf2.pc.in' not found

[Keith W]

Hi

I'm running into problems building cpp on trunk this morning.  The
configure step is failing.  Is there a new dependency or some extra
commands I need to run?  I'm on RHEL 5.3 but I notice the same
failiure occuring on the Jenkins ubuntu slaves.

cd qpid/cpp
./bootstrap;
./configure

cheers Keith.

(snip)
config.status: error: cannot find input file: src/qmf2.pc.in
 cd . && /bin/sh
/home/keith/src/apache/qpid/qpid/cpp/build-aux/missing --run
automake-1.9 --foreign
configure.ac:551: required file `src/qmf2.pc.in' not found
make: *** [Makefile.in] Error 1
(snip)

-
Apache Qpid - AMQP Messaging Implementation
Project:  http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org

Re: svn commit: r1034108 - /qpid/trunk/qpid/cpp/bindings/qmf2/examples/cpp/list_agents.cpp

[Brad Hubbard]

On 11/12/2010 06:41 AM, tr...@apache.org wrote:

> URL: http://svn.apache.org/viewvc?rev=1034108&view=rev
> Log:
> Added a blank setAgentFilter (will make this a command option).
> Added an indication for the connected broker agent in the list.
> 
> Modified:
> qpid/trunk/qpid/cpp/bindings/qmf2/examples/cpp/list_agents.cpp

Thanks Ted,

That makes it crystal clear.

Cheers,
Brad

-
Apache Qpid - AMQP Messaging Implementation
Project:  http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org

[jira] [Created] (QPID-6015) python QMF2 console raises exception due to HA subscriptions.

[Alan Conway (JIRA)]

Alan Conway created QPID-6015:
-

 Summary: python QMF2 console raises exception due to HA 
subscriptions.
 Key: QPID-6015
 URL: https://issues.apache.org/jira/browse/QPID-6015
 Project: Qpid
  Issue Type: Bug
  Components: C++ Clustering
Affects Versions: 0.28
Reporter: Alan Conway
Assignee: Alan Conway


A python qmf console that queries subscriptions can crash when used with a HA 
cluster. 

To reproduce:

1. Start a 3 node HA cluster
2. qpid-send -b 20.0.20.200 -m 1000 -a 'qq;{create:always}'
3. Kill the primary, let the cluster fail over.
4. qpid-stat -u -b 20.0.20.200

Result:
Failed: IndexError - pop from empty list

Expected result:
No error.

See also: https://bugzilla.redhat.com/show_bug.cgi?id=1117708



--
This message was sent by Atlassian JIRA
(v6.2#6252)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

RE: Problems building trunk cpp broker since this morning - `src/qmf2.pc.in' not found

[Steve Huston]

The cmake build failed last night as well... couldn't configure:

CMake Error: File /qpidbuilds/trunk/qpid/cpp/src/qmf2.pc.in does not
exist.
CMake Error at src/CMakeLists.txt:1369 (configure_file):
  configure_file Problem configuring file

> -Original Message-
> From: Keith W [mailto:keith.w...@gmail.com]
> Sent: Friday, November 11, 2011 3:28 AM
> To: dev@qpid.apache.org
> Subject: Problems building trunk cpp broker since this morning -
> `src/qmf2.pc.in' not found
> 
> Hi
> 
> I'm running into problems building cpp on trunk this morning.  The
configure
> step is failing.  Is there a new dependency or some extra commands I
need
> to run?  I'm on RHEL 5.3 but I notice the same failiure occuring on the
Jenkins
> ubuntu slaves.
> 
> cd qpid/cpp
> ./bootstrap;
> ./configure
> 
> cheers Keith.
> 
> (snip)
> config.status: error: cannot find input file: src/qmf2.pc.in  cd . &&
/bin/sh
> /home/keith/src/apache/qpid/qpid/cpp/build-aux/missing --run
> automake-1.9 --foreign
> configure.ac:551: required file `src/qmf2.pc.in' not found
> make: *** [Makefile.in] Error 1
> (snip)
> 
> -
> Apache Qpid - AMQP Messaging Implementation
> Project:  http://qpid.apache.org
> Use/Interact: mailto:dev-subscr...@qpid.apache.org


-
Apache Qpid - AMQP Messaging Implementation
Project:  http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org

RE: Problems building trunk cpp broker since this morning - `src/qmf2.pc.in' not found

[Andrew Stitcher]

On Fri, 2011-11-11 at 08:32 -0600, Steve Huston wrote:
> The cmake build failed last night as well... couldn't configure:
> 
> CMake Error: File /qpidbuilds/trunk/qpid/cpp/src/qmf2.pc.in does not
> exist.
> CMake Error at src/CMakeLists.txt:1369 (configure_file):
>   configure_file Problem configuring file

Mea Culpa - I missed adding the necessary new file!

Andrew



-
Apache Qpid - AMQP Messaging Implementation
Project:  http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org

Re: Problems building trunk cpp broker since this morning - `src/qmf2.pc.in' not found

[Robbie Gemmell]

This kind of thing seems like a good reason to add a CMake build
project to Jenkins (or, you know, just have 1 build system :p) in
addition to the autotools build Keith set up. Any takers?

On 11 November 2011 14:52, Andrew Stitcher  wrote:
> On Fri, 2011-11-11 at 08:32 -0600, Steve Huston wrote:
>> The cmake build failed last night as well... couldn't configure:
>>
>> CMake Error: File /qpidbuilds/trunk/qpid/cpp/src/qmf2.pc.in does not
>> exist.
>> CMake Error at src/CMakeLists.txt:1369 (configure_file):
>>   configure_file Problem configuring file
>
> Mea Culpa - I missed adding the necessary new file!
>
> Andrew
>
>
>
> -
> Apache Qpid - AMQP Messaging Implementation
> Project:      http://qpid.apache.org
> Use/Interact: mailto:dev-subscr...@qpid.apache.org
>
>

-
Apache Qpid - AMQP Messaging Implementation
Project:  http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org

[jira] [Created] (QPID-4413) cmake build puts qpid.pc and qmf2.pc in wrong place

[Steve Huston (JIRA)]

Steve Huston created QPID-4413:
--

 Summary: cmake build puts qpid.pc and qmf2.pc in wrong place
 Key: QPID-4413
 URL: https://issues.apache.org/jira/browse/QPID-4413
 Project: Qpid
  Issue Type: Bug
  Components: Build Tools
Affects Versions: 0.19
 Environment: cmake build
Reporter: Steve Huston
Assignee: Steve Huston
Priority: Minor


The cmake build generates qpid.pc and qmf2.pc but leaves them in the current 
directory, not in CMAKE_CURRENT_BINARY_DIR, where the install step expects to 
pick them up from.

--
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

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Resolved] (QPID-4413) cmake build puts qpid.pc and qmf2.pc in wrong place

[Steve Huston (JIRA)]

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

Steve Huston resolved QPID-4413.


   Resolution: Fixed
Fix Version/s: 0.19

Fixed on trunk r1405106.

> cmake build puts qpid.pc and qmf2.pc in wrong place
> ---
>
> Key: QPID-4413
> URL: https://issues.apache.org/jira/browse/QPID-4413
> Project: Qpid
>  Issue Type: Bug
>  Components: Build Tools
>Affects Versions: 0.19
> Environment: cmake build
>Reporter: Steve Huston
>Assignee: Steve Huston
>Priority: Minor
> Fix For: 0.19
>
>
> The cmake build generates qpid.pc and qmf2.pc but leaves them in the current 
> directory, not in CMAKE_CURRENT_BINARY_DIR, where the install step expects to 
> pick them up from.

--
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

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Created] (QPID-6059) Java QMF2 Agent code made some now invalid assumptions about replyTo

[Fraser Adams (JIRA)]

Fraser Adams created QPID-6059:
--

 Summary: Java QMF2 Agent code made some now invalid assumptions 
about replyTo
 Key: QPID-6059
 URL: https://issues.apache.org/jira/browse/QPID-6059
 Project: Qpid
  Issue Type: Bug
  Components: Java Tools
Reporter: Fraser Adams
Priority: Minor


The Java QMF2 Agent code made some now invalid assumptions about replyTo (it 
assumed that replyTo addresses would be bound to qmf.default.direct or 
qmf.default.topic) and used this assumption to optimise replies and work around 
a bug in older versions of the JMS client that caused spurious exchangeDeclares 
when invoking send() on the replyTo.

The assumption that was made is still valid for most QMF clients, but there's 
no reason why a client's reply queue has to be bound to qmf.default.direct or 
qmf.default.topic.

This fix adds an additional clause to the sendResponse code that falls back to 
using the actual replyTo Destination if the reply address isn't bound to one of 
the qmf exchanges.




--
This message was sent by Atlassian JIRA
(v6.2#6252)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (QPID-6059) Java QMF2 Agent code made some now invalid assumptions about replyTo

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on QPID-6059:
---

Commit 1621430 from [~fadams] in branch 'qpid/trunk'
[ https://svn.apache.org/r1621430 ]

QPID-6059: Java QMF2 Agent code made some now invalid assumptions about replyTo

> Java QMF2 Agent code made some now invalid assumptions about replyTo
> 
>
> Key: QPID-6059
> URL: https://issues.apache.org/jira/browse/QPID-6059
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Tools
>Reporter: Fraser Adams
>    Priority: Minor
>
> The Java QMF2 Agent code made some now invalid assumptions about replyTo (it 
> assumed that replyTo addresses would be bound to qmf.default.direct or 
> qmf.default.topic) and used this assumption to optimise replies and work 
> around a bug in older versions of the JMS client that caused spurious 
> exchangeDeclares when invoking send() on the replyTo.
> The assumption that was made is still valid for most QMF clients, but there's 
> no reason why a client's reply queue has to be bound to qmf.default.direct or 
> qmf.default.topic.
> This fix adds an additional clause to the sendResponse code that falls back 
> to using the actual replyTo Destination if the reply address isn't bound to 
> one of the qmf exchanges.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Resolved] (QPID-6059) Java QMF2 Agent code made some now invalid assumptions about replyTo

[Fraser Adams (JIRA)]

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

Fraser Adams resolved QPID-6059.


Resolution: Fixed

> Java QMF2 Agent code made some now invalid assumptions about replyTo
> 
>
> Key: QPID-6059
> URL: https://issues.apache.org/jira/browse/QPID-6059
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Tools
>Reporter: Fraser Adams
>    Priority: Minor
>
> The Java QMF2 Agent code made some now invalid assumptions about replyTo (it 
> assumed that replyTo addresses would be bound to qmf.default.direct or 
> qmf.default.topic) and used this assumption to optimise replies and work 
> around a bug in older versions of the JMS client that caused spurious 
> exchangeDeclares when invoking send() on the replyTo.
> The assumption that was made is still valid for most QMF clients, but there's 
> no reason why a client's reply queue has to be bound to qmf.default.direct or 
> qmf.default.topic.
> This fix adds an additional clause to the sendResponse code that falls back 
> to using the actual replyTo Destination if the reply address isn't bound to 
> one of the qmf exchanges.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Closed] (QPID-6059) Java QMF2 Agent code made some now invalid assumptions about replyTo

[Fraser Adams (JIRA)]

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

Fraser Adams closed QPID-6059.
--


> Java QMF2 Agent code made some now invalid assumptions about replyTo
> 
>
> Key: QPID-6059
> URL: https://issues.apache.org/jira/browse/QPID-6059
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Tools
>Reporter: Fraser Adams
>    Priority: Minor
>
> The Java QMF2 Agent code made some now invalid assumptions about replyTo (it 
> assumed that replyTo addresses would be bound to qmf.default.direct or 
> qmf.default.topic) and used this assumption to optimise replies and work 
> around a bug in older versions of the JMS client that caused spurious 
> exchangeDeclares when invoking send() on the replyTo.
> The assumption that was made is still valid for most QMF clients, but there's 
> no reason why a client's reply queue has to be bound to qmf.default.direct or 
> qmf.default.topic.
> This fix adds an additional clause to the sendResponse code that falls back 
> to using the actual replyTo Destination if the reply address isn't bound to 
> one of the qmf exchanges.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Resolved] (QPID-5820) Update QMF2 plugin wrt changes made to Broker mode during 0.29

[Keith Wall (JIRA)]

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

Keith Wall resolved QPID-5820.
--
Resolution: Fixed

> Update QMF2 plugin wrt changes made to Broker mode during 0.29
> --
>
> Key: QPID-5820
> URL: https://issues.apache.org/jira/browse/QPID-5820
> Project: Qpid
>  Issue Type: Task
>  Components: Java Broker, Qpid Managment Framework
>Reporter: Keith Wall
>Assignee: Fraser Adams
> Fix For: 0.29
>
>
> Changes made during 0.29 have changed the Broker's model and this has broken 
> qpid-broker-plugins-management-qmf2.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Created] (QPID-5820) Update QMF2 plugin wrt changes made to Broker mode during 0.29

[Keith Wall (JIRA)]

Keith Wall created QPID-5820:


 Summary: Update QMF2 plugin wrt changes made to Broker mode during 
0.29
 Key: QPID-5820
 URL: https://issues.apache.org/jira/browse/QPID-5820
 Project: Qpid
  Issue Type: Task
  Components: Java Broker
Reporter: Keith Wall
 Fix For: 0.29


Changes made during 0.29 have changed the Broker's model and this has broken 
qpid-broker-plugins-management-qmf2.





--
This message was sent by Atlassian JIRA
(v6.2#6252)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Updated] (QPID-5820) Update QMF2 plugin wrt changes made to Broker mode during 0.29

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-5820:
-

Component/s: Qpid Managment Framework

> Update QMF2 plugin wrt changes made to Broker mode during 0.29
> --
>
> Key: QPID-5820
> URL: https://issues.apache.org/jira/browse/QPID-5820
> Project: Qpid
>  Issue Type: Task
>  Components: Java Broker, Qpid Managment Framework
>Reporter: Keith Wall
> Fix For: 0.29
>
>
> Changes made during 0.29 have changed the Broker's model and this has broken 
> qpid-broker-plugins-management-qmf2.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (QPID-5820) Update QMF2 plugin wrt changes made to Broker mode during 0.29

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on QPID-5820:
---

Commit 1606812 from [~k-wall] in branch 'qpid/trunk'
[ https://svn.apache.org/r1606812 ]

QPID-5820: [Java QMF2 Plugin] changes to plugin owing to the Java Broker model 
updates made during 0.29

* VHNs (virtualhostnodes) may exist within a VH (virtualhost)
* Use Port#availableProtocols rather than Port#protocols when trying to find 
the AMQP port
* Like the CPP Broker, Binding#arguments will be null if the binding was 
created with none.

Note that the QMF plugin still does not support virtualhosts created at 
runtime.  They'll be ignored until
the next restart.

Work done by Andrew MacBean  and me.

> Update QMF2 plugin wrt changes made to Broker mode during 0.29
> --
>
> Key: QPID-5820
> URL: https://issues.apache.org/jira/browse/QPID-5820
> Project: Qpid
>  Issue Type: Task
>  Components: Java Broker, Qpid Managment Framework
>Reporter: Keith Wall
> Fix For: 0.29
>
>
> Changes made during 0.29 have changed the Broker's model and this has broken 
> qpid-broker-plugins-management-qmf2.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (QPID-5820) Update QMF2 plugin wrt changes made to Broker mode during 0.29

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on QPID-5820:
---

Commit 1607034 from [~k-wall] in branch 'qpid/trunk'
[ https://svn.apache.org/r1607034 ]

QPID-5820: [Java QMF2 Plugin] changes to plugin owing to the Java Broker model 
updates made during 0.29

* Used model getters rather than named attributes wherever possible

Work done by Andrew MacBean  and me.

> Update QMF2 plugin wrt changes made to Broker mode during 0.29
> --
>
> Key: QPID-5820
> URL: https://issues.apache.org/jira/browse/QPID-5820
> Project: Qpid
>  Issue Type: Task
>  Components: Java Broker, Qpid Managment Framework
>Reporter: Keith Wall
> Fix For: 0.29
>
>
> Changes made during 0.29 have changed the Broker's model and this has broken 
> qpid-broker-plugins-management-qmf2.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Updated] (QPID-5820) Update QMF2 plugin wrt changes made to Broker mode during 0.29

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-5820:
-

Assignee: Fraser Adams  (was: Keith Wall)

> Update QMF2 plugin wrt changes made to Broker mode during 0.29
> --
>
> Key: QPID-5820
> URL: https://issues.apache.org/jira/browse/QPID-5820
> Project: Qpid
>  Issue Type: Task
>  Components: Java Broker, Qpid Managment Framework
>Reporter: Keith Wall
>Assignee: Fraser Adams
> Fix For: 0.29
>
>
> Changes made during 0.29 have changed the Broker's model and this has broken 
> qpid-broker-plugins-management-qmf2.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Updated] (QPID-5820) Update QMF2 plugin wrt changes made to Broker mode during 0.29

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-5820:
-

Status: Reviewable  (was: In Progress)

> Update QMF2 plugin wrt changes made to Broker mode during 0.29
> --
>
> Key: QPID-5820
> URL: https://issues.apache.org/jira/browse/QPID-5820
> Project: Qpid
>  Issue Type: Task
>  Components: Java Broker, Qpid Managment Framework
>Reporter: Keith Wall
>Assignee: Keith Wall
> Fix For: 0.29
>
>
> Changes made during 0.29 have changed the Broker's model and this has broken 
> qpid-broker-plugins-management-qmf2.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Assigned] (QPID-5820) Update QMF2 plugin wrt changes made to Broker mode during 0.29

[Keith Wall (JIRA)]

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

Keith Wall reassigned QPID-5820:


Assignee: Keith Wall

> Update QMF2 plugin wrt changes made to Broker mode during 0.29
> --
>
> Key: QPID-5820
> URL: https://issues.apache.org/jira/browse/QPID-5820
> Project: Qpid
>  Issue Type: Task
>  Components: Java Broker, Qpid Managment Framework
>Reporter: Keith Wall
>Assignee: Keith Wall
> Fix For: 0.29
>
>
> Changes made during 0.29 have changed the Broker's model and this has broken 
> qpid-broker-plugins-management-qmf2.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (QPID-5820) Update QMF2 plugin wrt changes made to Broker mode during 0.29

[Keith Wall (JIRA)]

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

Keith Wall commented on QPID-5820:
--

Fraser,

Andrew and I made changes to get the QMF2 plugin functional again, and tested 
the changes manually using the UI.  All seems good to us - would you be able to 
take a look too?





> Update QMF2 plugin wrt changes made to Broker mode during 0.29
> --
>
> Key: QPID-5820
> URL: https://issues.apache.org/jira/browse/QPID-5820
> Project: Qpid
>  Issue Type: Task
>  Components: Java Broker, Qpid Managment Framework
>Reporter: Keith Wall
>Assignee: Fraser Adams
> Fix For: 0.29
>
>
> Changes made during 0.29 have changed the Broker's model and this has broken 
> qpid-broker-plugins-management-qmf2.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (QPID-5820) Update QMF2 plugin wrt changes made to Broker mode during 0.29

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on QPID-5820:
---

Commit 1608025 from [~fadams] in branch 'qpid/trunk'
[ https://svn.apache.org/r1608025 ]

JIRA:QPID-5820 Added some defensive code to qmf-ui.js to protect against the 
case when null binding arguments get returned. Fixed bug in broker-core 
BindingImpl.java whereby the binding arguments were not being set on 
construction which caused getArguments to always return null

> Update QMF2 plugin wrt changes made to Broker mode during 0.29
> --
>
> Key: QPID-5820
> URL: https://issues.apache.org/jira/browse/QPID-5820
> Project: Qpid
>  Issue Type: Task
>  Components: Java Broker, Qpid Managment Framework
>Reporter: Keith Wall
>Assignee: Fraser Adams
> Fix For: 0.29
>
>
> Changes made during 0.29 have changed the Broker's model and this has broken 
> qpid-broker-plugins-management-qmf2.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (QPID-5820) Update QMF2 plugin wrt changes made to Broker mode during 0.29

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on QPID-5820:
---

Commit 1608201 from [~fadams] in branch 'qpid/trunk'
[ https://svn.apache.org/r1608201 ]

QPID-5820: added better fix to the problem of arguments not being set. The real 
issue turned out to be that the create method on BindingImpl was being called 
by AbstractExchange after it called addBinding, but the addBinding method is 
the one that results in the QMF Binding instance being created. In other words 
the QMF Binding instance was getting constructed before the 
resolveAutomatedAttribute stuff

> Update QMF2 plugin wrt changes made to Broker mode during 0.29
> --
>
> Key: QPID-5820
> URL: https://issues.apache.org/jira/browse/QPID-5820
> Project: Qpid
>  Issue Type: Task
>  Components: Java Broker, Qpid Managment Framework
>Reporter: Keith Wall
>Assignee: Fraser Adams
> Fix For: 0.29
>
>
> Changes made during 0.29 have changed the Broker's model and this has broken 
> qpid-broker-plugins-management-qmf2.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Created] (QPID-7446) Allow Java QMF2 plugin to compile against the 6.0.x broker

[Rob Godfrey (JIRA)]

Rob Godfrey created QPID-7446:
-

 Summary: Allow Java QMF2 plugin to compile against the 6.0.x broker
 Key: QPID-7446
 URL: https://issues.apache.org/jira/browse/QPID-7446
 Project: Qpid
  Issue Type: Bug
  Components: Java Tools, Qpid Managment Framework
Reporter: Rob Godfrey
Assignee: Ted Ross






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (QPID-7446) Allow Java QMF2 plugin to compile against the 6.0.x broker

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on QPID-7446:
---

Commit 1763292 from [~godfrer] in branch 'qpid/trunk'
[ https://svn.apache.org/r1763292 ]

QPID-7446 : Allow the QMF2 plugin to compile against the 6.0.x java codebase

> Allow Java QMF2 plugin to compile against the 6.0.x broker
> --
>
> Key: QPID-7446
> URL: https://issues.apache.org/jira/browse/QPID-7446
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Tools, Qpid Managment Framework
>Reporter: Rob Godfrey
>Assignee: Ted Ross
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

Remove autotools? [Was: Problems building trunk cpp broker since this morning - `src/qmf2.pc.in' not found]

[Andrew Stitcher]

On Fri, 2011-11-11 at 15:24 +, Robbie Gemmell wrote:
> This kind of thing seems like a good reason to add a CMake build
> project to Jenkins (or, you know, just have 1 build system :p) in
> addition to the autotools build Keith set up. Any takers?

Personally I go for the 1 build system - Cmake.

At present Cmake is very nearly at parity with autotools (given the
recent work I checked in from Jan-Marek Glogowski) and I'd say it would
be feasible (given the available time) to remove autotools and shift to
cmake in the 0.16 time frame.

I think the only remaining work is to make the tests on cmake be at
parity with autotools.

[There's also tidying work we should do, because neither of the build
systems is very pretty or very maintainable at this point, but having
just one would help a lot]

Andrew



-
Apache Qpid - AMQP Messaging Implementation
Project:  http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org

management, what should the future look like? (was Re: Location for Java QMF2 code + QMF GUI)

[Gordon Sim]

On 03/25/2013 06:32 PM, Fraser Adams wrote:

If there's strength of feeling that extras is more appropriate then
that's fine and I'll be OK with that, but then the location of the ruby
stuff seems inconsistent (I'm not knocking the ruby stuff, just trying
to figure the most consistent place).


I think you make a good case there and I certainly have no objections to 
it going under tools.



The "stand alone project" thing is interesting, there was talk of this
for QMF last year but it didn't sprout wings, and I guess probably
won't. Perhaps it might be time for a proper concerted think about
"management" in general. Rob looks like he might announce some stuff
from OASIS on AMQP management in the near future, so perhaps the time is
ripe to move all the management stuff into a new space to start the ball
rolling on that general trajectory?


I think it very much is a good time to start thinking about management 
in general. I'm not sure I would begin by moving the existing stuff 
around though.


I think I would begin by discussing what we all individually and 
collectively want from management.


-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Created] (QPID-5614) Fix Java Broker QMF2 Plugin problems caused by refactoring in QPID-5578

[Fraser Adams (JIRA)]

Fraser Adams created QPID-5614:
--

 Summary: Fix Java Broker QMF2 Plugin problems caused by 
refactoring in QPID-5578
 Key: QPID-5614
 URL: https://issues.apache.org/jira/browse/QPID-5614
 Project: Qpid
  Issue Type: Bug
Reporter: Fraser Adams


QPID-5578 resulted in a lot of changes to the Java Broker Management Model 
unfortunately those changes trashed the QMF2 Management Plugin.

This Jira relates to the work to fix the QMF2 Management Plugin.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (QPID-5614) Fix Java Broker QMF2 Plugin problems caused by refactoring in QPID-5578

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on QPID-5614:
---

Commit 1575530 from [~fadams] in branch 'qpid/trunk'
[ https://svn.apache.org/r1575530 ]

QPID-5614: Initial fix of the issues. The QMF2 Plugin compiles again and mostly 
works, but there are issues with the bindings and subscriptions - though I 
think that this might be a problem with the Java Broker Management Model

> Fix Java Broker QMF2 Plugin problems caused by refactoring in QPID-5578
> ---
>
> Key: QPID-5614
> URL: https://issues.apache.org/jira/browse/QPID-5614
> Project: Qpid
>  Issue Type: Bug
>Reporter: Fraser Adams
>
> QPID-5578 resulted in a lot of changes to the Java Broker Management Model 
> unfortunately those changes trashed the QMF2 Management Plugin.
> This Jira relates to the work to fix the QMF2 Management Plugin.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (QPID-5614) Fix Java Broker QMF2 Plugin problems caused by refactoring in QPID-5578

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on QPID-5614:
---

Commit 1575533 from [~fadams] in branch 'qpid/trunk'
[ https://svn.apache.org/r1575533 ]

QPID-5614: Fix problems caused by changes to Java Broker Logging in QPID-5611

> Fix Java Broker QMF2 Plugin problems caused by refactoring in QPID-5578
> ---
>
> Key: QPID-5614
> URL: https://issues.apache.org/jira/browse/QPID-5614
> Project: Qpid
>  Issue Type: Bug
>Reporter: Fraser Adams
>
> QPID-5578 resulted in a lot of changes to the Java Broker Management Model 
> unfortunately those changes trashed the QMF2 Management Plugin.
> This Jira relates to the work to fix the QMF2 Management Plugin.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (QPID-5614) Fix Java Broker QMF2 Plugin problems caused by refactoring in QPID-5578

[Rob Godfrey (JIRA)]

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

Rob Godfrey commented on QPID-5614:
---

bq. The QMF2 Plugin compiles again and mostly works, but there are issues with 
the bindings and subscriptions - though I think that this might be a problem 
with the Java Broker Management Model

What's the nature of the issues you are seeing?



> Fix Java Broker QMF2 Plugin problems caused by refactoring in QPID-5578
> ---
>
> Key: QPID-5614
> URL: https://issues.apache.org/jira/browse/QPID-5614
> Project: Qpid
>  Issue Type: Bug
>Reporter: Fraser Adams
>
> QPID-5578 resulted in a lot of changes to the Java Broker Management Model 
> unfortunately those changes trashed the QMF2 Management Plugin.
> This Jira relates to the work to fix the QMF2 Management Plugin.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Resolved] (QPID-5614) Fix Java Broker QMF2 Plugin problems caused by refactoring in QPID-5578

[Fraser Adams (JIRA)]

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

Fraser Adams resolved QPID-5614.


Resolution: Fixed

> Fix Java Broker QMF2 Plugin problems caused by refactoring in QPID-5578
> ---
>
> Key: QPID-5614
> URL: https://issues.apache.org/jira/browse/QPID-5614
> Project: Qpid
>  Issue Type: Bug
>Reporter: Fraser Adams
>
> QPID-5578 resulted in a lot of changes to the Java Broker Management Model 
> unfortunately those changes trashed the QMF2 Management Plugin.
> This Jira relates to the work to fix the QMF2 Management Plugin.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Updated] (QPID-5614) Fix Java Broker QMF2 Plugin problems caused by refactoring in QPID-5578

[Justin Ross (JIRA)]

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

Justin Ross updated QPID-5614:
--
Component/s: Java Broker

> Fix Java Broker QMF2 Plugin problems caused by refactoring in QPID-5578
> ---
>
> Key: QPID-5614
> URL: https://issues.apache.org/jira/browse/QPID-5614
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Reporter: Fraser Adams
>
> QPID-5578 resulted in a lot of changes to the Java Broker Management Model 
> unfortunately those changes trashed the QMF2 Management Plugin.
> This Jira relates to the work to fix the QMF2 Management Plugin.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

Re: Remove autotools? [Was: Problems building trunk cpp broker since this morning - `src/qmf2.pc.in' not found]

[Cliff Jansen]

+1

An additional sub-task would be to rework the separate powershell and
sh scripts within cmake/ctest to a single base (python is a likely
candidate), so that contributers don't need to wear multiple hats.

On Fri, Nov 11, 2011 at 7:53 AM, Andrew Stitcher  wrote:
> On Fri, 2011-11-11 at 15:24 +, Robbie Gemmell wrote:
>> This kind of thing seems like a good reason to add a CMake build
>> project to Jenkins (or, you know, just have 1 build system :p) in
>> addition to the autotools build Keith set up. Any takers?
>
> Personally I go for the 1 build system - Cmake.
>
> At present Cmake is very nearly at parity with autotools (given the
> recent work I checked in from Jan-Marek Glogowski) and I'd say it would
> be feasible (given the available time) to remove autotools and shift to
> cmake in the 0.16 time frame.
>
> I think the only remaining work is to make the tests on cmake be at
> parity with autotools.
>
> [There's also tidying work we should do, because neither of the build
> systems is very pretty or very maintainable at this point, but having
> just one would help a lot]
>
> Andrew
>
>
>
> -
> Apache Qpid - AMQP Messaging Implementation
> Project:      http://qpid.apache.org
> Use/Interact: mailto:dev-subscr...@qpid.apache.org
>
>

-
Apache Qpid - AMQP Messaging Implementation
Project:  http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org

RE: Remove autotools? [Was: Problems building trunk cpp broker since this morning - `src/qmf2.pc.in' not found]

[Steve Huston]

+20 :-)

> -Original Message-
> From: Cliff Jansen [mailto:cliffjan...@gmail.com]
> Sent: Friday, November 11, 2011 12:02 PM
> To: dev@qpid.apache.org
> Subject: Re: Remove autotools? [Was: Problems building trunk cpp broker
> since this morning - `src/qmf2.pc.in' not found]
>
> +1
>
> An additional sub-task would be to rework the separate powershell and sh
> scripts within cmake/ctest to a single base (python is a likely
candidate), so
> that contributers don't need to wear multiple hats.
>
> On Fri, Nov 11, 2011 at 7:53 AM, Andrew Stitcher 
> wrote:
> > On Fri, 2011-11-11 at 15:24 +, Robbie Gemmell wrote:
> >> This kind of thing seems like a good reason to add a CMake build
> >> project to Jenkins (or, you know, just have 1 build system :p) in
> >> addition to the autotools build Keith set up. Any takers?
> >
> > Personally I go for the 1 build system - Cmake.
> >
> > At present Cmake is very nearly at parity with autotools (given the
> > recent work I checked in from Jan-Marek Glogowski) and I'd say it
> > would be feasible (given the available time) to remove autotools and
> > shift to cmake in the 0.16 time frame.
> >
> > I think the only remaining work is to make the tests on cmake be at
> > parity with autotools.
> >
> > [There's also tidying work we should do, because neither of the build
> > systems is very pretty or very maintainable at this point, but having
> > just one would help a lot]
> >
> > Andrew
> >
> >
> >
> > -
> > Apache Qpid - AMQP Messaging Implementation
> > Project:      http://qpid.apache.org
> > Use/Interact: mailto:dev-subscr...@qpid.apache.org
> >
> >
>
> -
> Apache Qpid - AMQP Messaging Implementation
> Project:  http://qpid.apache.org
> Use/Interact: mailto:dev-subscr...@qpid.apache.org


-
Apache Qpid - AMQP Messaging Implementation
Project:  http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org