Re: Qpid 0.8 RC2 available for download ** Please Test **

2010-11-16 Thread Emmanuel Bourg

Hi,

I've found a minor issue with the Java broker. On Debian the qpid.start 
script doesn't work:


ebo...@sirius:~/qpid-broker-0.8/bin$ ./qpid.start
./qpid.start: line 21: exec: qpid-server: not found

I had to replace "exec" with "sh" to get it to work.

Emmanuel Bourg



Le 14/11/2010 23:22, Robbie Gemmell a écrit :

Hi all,

Qpid 0.8 RC2 can nowbe found for download at:
http://people.apache.org/~robbie/qpid/0.8/RC2/

There were no changes from the output for RC1, but the output from running
RAT across the 'full release' RC2 archive can be found at the following URL:
http://people.apache.org/~robbie/qpid/0.8/0.8rc2_rat_output.txt

*Please* take the time to download and try out this release candidate and
report your results, such that any additional issues which require
addressing before the release can proceed are identified as early as
possible. If no issues are reported that require a new RC to be produced,
RC2 will be taken to vote by the end of the week.

Thanks,
Robbie

For the record, the changes since RC1 are:

- QPID-2674: prevent heartbeats causing segmentation faults
- QPID-2940: clean up message-accept records automatically
- QPID-2941: fix error in recovery handling for new CLFS store
- QPID-2942: enable the Java broker convenience package to be started
out-of-the-box
- QPID-2943: add the examples to the Java client convenience package
- QPID-2946: exclude the QMan convenience package from the release (due to
QPID-2945)
- Update to always include cluster scripts in the C++ distribution
regardless of dependency install status on the build box


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






smime.p7s
Description: S/MIME Cryptographic Signature


[jira] Resolved: (QPID-2948) Generated API docs have extraneous macro names in method signatures

2010-11-16 Thread Steve Huston (JIRA)

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

Steve Huston resolved QPID-2948.


   Resolution: Fixed
Fix Version/s: 0.8

Also merged into 0.8-release branch r1035652.

> Generated API docs have extraneous macro names in method signatures
> ---
>
> Key: QPID-2948
> URL: https://issues.apache.org/jira/browse/QPID-2948
> Project: Qpid
>  Issue Type: Bug
>  Components: Documentation
>Affects Versions: 0.7
>Reporter: Steve Huston
>Assignee: Steve Huston
> Fix For: 0.8
>
>
> The doxygen-generated docs for the qpid::messaging and qmf classes have the 
> DLL-exporting macros in the generated documentation. The doxygen options 
> (user.doxygen.in and developer.doxygen.in) predefine these macros for the 
> other libs so that the names don't appear in the generated documentation, but 
> these new libraries weren't added to the list of macros.

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


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



Re: Possible inclusions for RC3? Act now...

2010-11-16 Thread Robbie Gemmell
Gordon applied this change for the 0.6 release:
http://svn.apache.org/viewvc?rev=904458&view=rev

At the very least something similar for 0.8 will do. The final
'release notes' can just be a link to the auto-generated JIRA output,
but we should have a few things listed in the release email to call
out any major highlights. I started such a list on the wiki page I
made, https://cwiki.apache.org/confluence/display/qpid/0.8+Release ,
it would be good if everyone would please make suggestions for it.

Talking of JIRA, what are peoples thoughts on the version numbers
post-release? Should the 0.7 and 0.8 versions be merged together and
renamed 0.8 ? I think it might be more understandable for users, as
0.7 was never released. Currently there are items in both 0.7 and 0.8
versions and I would have to give links to both Release Notes outputs
to get a full picture of whats actually in the 0.8 release.

Robbie

On 16 November 2010 13:58, Alan Conway  wrote:
> On 11/15/2010 08:03 PM, Robbie Gemmell wrote:
>>
>> So, I have changed my mind about incorporating updates to RC2 to fix the
>> mostly documentation-related issues noted thus far; in the interests of
>> these changes actually getting made sooner rather than later (e.g. let's
>> say
>> the 0.10 RC stages :P), I will produce RC3 later in the week to
>> incorporate
>> such updates if they are made. Quid pro quo people.
>>
>> I include a summary list below of possible changes to the RC's mentioned
>> to
>> date for people familiar with the affected areas to action. I will update
>> the Java client/example readme.
>>
> [snip]
>>
>> There's an out of date RELEASE_NOTES file from the M4 release. Do we
>> overwrite
>> that each time or do we have a better way of getting release notes (e.g.
>> from
>> JIRAs)? It is referred to by README.txt so if we remove it we need to
>> update
>> that.
>
> Are we planning to do release notes for 0.8 release? They could be added to
> this file,  or if we're distributing them some other way we can delete it
> and put an appropriate pointer in the README.
>

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



Re: Possible inclusions for RC3? Act now...

2010-11-16 Thread Emmanuel Bourg

Le 16/11/2010 16:19, Robbie Gemmell a écrit :


Talking of JIRA, what are peoples thoughts on the version numbers
post-release? Should the 0.7 and 0.8 versions be merged together and
renamed 0.8 ? I think it might be more understandable for users, as
0.7 was never released. Currently there are items in both 0.7 and 0.8
versions and I would have to give links to both Release Notes outputs
to get a full picture of whats actually in the 0.8 release.


Merging the two versions in JIRA makes sense (0.7 becomes 0.8).

The release notes will have to explain why the version number jumped 
from 0.6 to 0.8, otherwise people will keep asking what happened to the 
0.7 release.


Personally I still think this release should have been Qpid 0.7 and not 
0.8, the alternatives to an odd/even numbering were never seriously 
discussed on the list.


Emmanuel Bourg



smime.p7s
Description: S/MIME Cryptographic Signature


Qpid version numbering (again)

2010-11-16 Thread Andrew Stitcher
On Tue, 2010-11-16 at 16:50 +0100, Emmanuel Bourg wrote:
> ...
> Personally I still think this release should have been Qpid 0.7 and not 
> 0.8, the alternatives to an odd/even numbering were never seriously 
> discussed on the list.

That's because we did discuss it on the list when we made the change
originally and it wasn't so long ago that it makes sense to change again
at this point.

It is true that is wasn't a particularly long discussion, but people had
an opportunity to talk about it then (about 1.5 years ago) and it isn't
broken enough (if it is broken at all) that we want to change it every
year or so.

At this point we have a clear version numbering scheme that allows you
tell at a glance if a version you have is released or development (this
is quite useful for bug reporting). It is a scheme that is used by other
open source projects and so shouldn't be too unexpected for our users
(Gnome uses this scheme for example).

Obviously all this is just my opinion, E&OE, YMMV etc.

Andrew




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



Re: Possible inclusions for RC3? Act now...

2010-11-16 Thread Andrew Stitcher
On Tue, 2010-11-16 at 15:19 +, Robbie Gemmell wrote:
> Gordon applied this change for the 0.6 release:
> http://svn.apache.org/viewvc?rev=904458&view=rev

> Talking of JIRA, what are peoples thoughts on the version numbers
> post-release? Should the 0.7 and 0.8 versions be merged together and
> renamed 0.8 ? I think it might be more understandable for users, as
> 0.7 was never released. Currently there are items in both 0.7 and 0.8
> versions and I would have to give links to both Release Notes outputs
> to get a full picture of whats actually in the 0.8 release.

I think that either:

* We retrospectively merge 0.7 & 0.8 together in Jira
* We make sure that the release notes point to both bugs fixed in 0.7 &
0.8.

Merging the revisions seems to lose some information, but I can't think
why it'd be important information.

It should be said though that with our numbering scheme you;d expect the
vast majority of bugs to be fixed in the preceding devel version,
although they probably should be targeted at a release version if there
is a target.

To have many bugs fixed in a release version would mean that there were
a lot of blocking bugs that delayed the release. The other way you;d get
this situation is if we put out bug fix releases, something we've not
done recently at least.

Andrew



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



RE: Possible inclusions for RC3? Act now...

2010-11-16 Thread Steve Huston
> -Original Message-
> From: Robbie Gemmell [mailto:robbie.gemm...@gmail.com] 
> ...
>
> Talking of JIRA, what are peoples thoughts on the version 
> numbers post-release? Should the 0.7 and 0.8 versions be 
> merged together and renamed 0.8 ? I think it might be more 
> understandable for users, as 0.7 was never released. 

I think it's a bad idea to merge the versions in JIRA. If someone
reported against 0.7, we know they are working in the dev stream. If
it's reported against 0.8 we can be fairly sure the user pulled a
release kit and is working with that.

> Currently there are items in both 0.7 and 0.8 versions and I 
> would have to give links to both Release Notes outputs to get 
> a full picture of whats actually in the 0.8 release.

Reporting what is fixed for 0.8 (since 0.6) can be a list of all the 0.7
and 0.8 fixes.

-Steve


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



[jira] Updated: (QPID-2874) Clustered broker crashes in assertion in cluster/ExpiryPolicy.cpp

2010-11-16 Thread Alan Conway (JIRA)

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

Alan Conway updated QPID-2874:
--

Attachment: reproduce.sh

Attached script reproduces the problem reliably, every time.

The problem is to do with messages that are fanned-out to multiple queues.
The cluster update process does not recognize the same message on different
queues and updates as if it were two distinct messages. The cluster expiry code
expects a 1-1 correspondence between messages and expiry-ids, which are
assigned per message, not per-queued-message.

> Clustered broker crashes in assertion in cluster/ExpiryPolicy.cpp
> -
>
> Key: QPID-2874
> URL: https://issues.apache.org/jira/browse/QPID-2874
> Project: Qpid
>  Issue Type: Bug
>  Components: C++ Clustering
>Affects Versions: 0.6
>Reporter: Alan Conway
>Assignee: Alan Conway
> Attachments: reproduce.sh
>
>
> From us...@qpid.apache.org:
> We have a Java node connecting to one of two Qpid brokers (0.5 or 0.6,
> doesn't matter, we get the same) as a client of another Java node 
> which acts
> as the server. The client sends messages over a queue, awaiting a 
> response
> message from the server on a temporary queue. Both brokers use 
> clustering
> (and are part of the same cluster). At some point, after 1 to 3 
> exchanges
> between the client and server nodes, both Qpid brokers simply crash, 
> without
> any error being logged. Broker logfile is attached. The typical 
> output that
> appears in the broker log files - the last line in the log is always 
> the
> same, so it seems that the place at which the failure occurs is 
> consistent.
> Original message with logs and config: 
> http://apache-qpid-users.2158936.n2.nabble.com/Qpid-clustering-broker-crash-tt5511801.html#a5511801
> Stack trace:
> [r...@ca-mtl1-tric-01 .qpidd]# gdb /opt/qpid/current/sbin/qpidd core.6709
> GNU gdb (GDB) Red Hat Enterprise Linux (7.0.1-23.el5_5.2)
> Copyright (C) 2009 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later 
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "i386-redhat-linux-gnu".
> For bug reporting instructions, please see:
> ...
> Reading symbols from /opt/qpid/qpid-0.5/sbin/qpidd...done.
> [New Thread 6732]
> [New Thread 6727]
> [New Thread 6721]
> [New Thread 6710]
> [New Thread 6709]
> warning: .dynamic section for "/usr/lib/libplc4.so" is not at the expected 
> address
> warning: difference appears to be caused by prelink, adjusting expectations
> warning: .dynamic section for "/usr/lib/libplds4.so" is not at the expected 
> address
> warning: difference appears to be caused by prelink, adjusting expectations
> warning: .dynamic section for "/usr/lib/openais/libcpg.so.2" is not at the 
> expected address
> warning: difference appears to be caused by prelink, adjusting expectations
> Reading symbols from /opt/qpid/current/lib/libqpidbroker.so.0...done.
> Loaded symbols for /opt/qpid/current/lib/libqpidbroker.so.0
> Reading symbols from /opt/qpid/current/lib/libqpidcommon.so.0...done.
> Loaded symbols for /opt/qpid/current/lib/libqpidcommon.so.0
> Reading symbols from /usr/lib/libboost_program_options.so.2...(no debugging 
> symbols found)...done.
> Loaded symbols for /usr/lib/libboost_program_options.so.2
> Reading symbols from /usr/lib/libboost_filesystem.so.2...(no debugging 
> symbols found)...done.
> Loaded symbols for /usr/lib/libboost_filesystem.so.2
> Reading symbols from /lib/libuuid.so.1...(no debugging symbols found)...done.
> Loaded symbols for /lib/libuuid.so.1
> Reading symbols from /lib/libdl.so.2...(no debugging symbols found)...done.
> Loaded symbols for /lib/libdl.so.2
> Reading symbols from /lib/librt.so.1...(no debugging symbols found)...done.
> Loaded symbols for /lib/librt.so.1
> Reading symbols from /usr/lib/libsasl2.so.2...(no debugging symbols 
> found)...done.
> Loaded symbols for /usr/lib/libsasl2.so.2
> Reading symbols from /usr/lib/libstdc++.so.6...(no debugging symbols 
> found)...done.
> Loaded symbols for /usr/lib/libstdc++.so.6
> Reading symbols from /lib/libm.so.6...(no debugging symbols found)...done.
> Loaded symbols for /lib/libm.so.6
> Reading symbols from /lib/libgcc_s.so.1...(no debugging symbols found)...done.
> Loaded symbols for /lib/libgcc_s.so.1
> Reading symbols from /lib/libc.so.6...(no debugging symbols found)...done.
> Loaded symbols for /lib/libc.so.6
> Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done.
> Loaded symbols for /lib/l

[jira] Created: (QPID-2949) broker prompts console interactively for password when --auth=no

2010-11-16 Thread michael j. goulish (JIRA)
broker prompts console interactively for password when --auth=no


 Key: QPID-2949
 URL: https://issues.apache.org/jira/browse/QPID-2949
 Project: Qpid
  Issue Type: Bug
  Components: C++ Broker
Affects Versions: 0.8
Reporter: michael j. goulish
Assignee: michael j. goulish
Priority: Minor
 Fix For: 0.8


As a result of checkin svn r1024541, which promoted some client-side Sasl code 
to the common library for use in broker, the broker now prompts for a password 
when when it is run with --auth=no  !

The attached patch removes this behavior by propagating knowledge of 
"--auth=no" down to SaslFactory.  If authorization has been turned off, the 
Saslfactory will create a null sasl object, just like it does if the code is 
compiled with no Sasl support.



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


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



[jira] Updated: (QPID-2949) broker prompts console interactively for password when --auth=no

2010-11-16 Thread michael j. goulish (JIRA)

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

michael j. goulish updated QPID-2949:
-

Attachment: dont_prompt_me.diff

This patch prevents the broker from prompting for a password when auth == no by 
sending that info down to the SaslFactory, through Connection and 
ConnectionHandler.The SaslFactory will create a null sasl object.


> broker prompts console interactively for password when --auth=no
> 
>
> Key: QPID-2949
> URL: https://issues.apache.org/jira/browse/QPID-2949
> Project: Qpid
>  Issue Type: Bug
>  Components: C++ Broker
>Affects Versions: 0.8
>Reporter: michael j. goulish
>Assignee: michael j. goulish
>Priority: Minor
> Fix For: 0.8
>
> Attachments: dont_prompt_me.diff
>
>
> As a result of checkin svn r1024541, which promoted some client-side Sasl 
> code to the common library for use in broker, the broker now prompts for a 
> password when when it is run with --auth=no  !
> The attached patch removes this behavior by propagating knowledge of 
> "--auth=no" down to SaslFactory.  If authorization has been turned off, the 
> Saslfactory will create a null sasl object, just like it does if the code is 
> compiled with no Sasl support.

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


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



[jira] Updated: (QPID-2949) broker prompts console interactively for password when --auth=no

2010-11-16 Thread michael j. goulish (JIRA)

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

michael j. goulish updated QPID-2949:
-

Description: 
As a result of checkin svn r1024541, which promoted some client-side Sasl code 
to the common library for use in broker, the broker now prompts for a password 
when when it is run with --auth=no  !

The attached patch removes this behavior by propagating knowledge of 
"--auth=no" down to SaslFactory.  If authorization has been turned off, the 
Saslfactory will create a null sasl object, just like it does if the code is 
compiled with no Sasl support.


TODO -- also must fix the pathway where auth==yes.

NOTE: this is apparently an irritant rather than a disaster, since it did not 
affect make check after the original checkin ( r102451 ).

  was:
As a result of checkin svn r1024541, which promoted some client-side Sasl code 
to the common library for use in broker, the broker now prompts for a password 
when when it is run with --auth=no  !

The attached patch removes this behavior by propagating knowledge of 
"--auth=no" down to SaslFactory.  If authorization has been turned off, the 
Saslfactory will create a null sasl object, just like it does if the code is 
compiled with no Sasl support.




> broker prompts console interactively for password when --auth=no
> 
>
> Key: QPID-2949
> URL: https://issues.apache.org/jira/browse/QPID-2949
> Project: Qpid
>  Issue Type: Bug
>  Components: C++ Broker
>Affects Versions: 0.8
>Reporter: michael j. goulish
>Assignee: michael j. goulish
>Priority: Minor
> Fix For: 0.8
>
> Attachments: dont_prompt_me.diff
>
>
> As a result of checkin svn r1024541, which promoted some client-side Sasl 
> code to the common library for use in broker, the broker now prompts for a 
> password when when it is run with --auth=no  !
> The attached patch removes this behavior by propagating knowledge of 
> "--auth=no" down to SaslFactory.  If authorization has been turned off, the 
> Saslfactory will create a null sasl object, just like it does if the code is 
> compiled with no Sasl support.
> TODO -- also must fix the pathway where auth==yes.
> NOTE: this is apparently an irritant rather than a disaster, since it did not 
> affect make check after the original checkin ( r102451 ).

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


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



Re: Qpid 0.8 RC2 available for download ** Please Test **

2010-11-16 Thread Chuck Rolke
Qpid 0.8 RC2 builds the WinSDK properly. WinSDK examples compile and pass smoke 
tests.

Note that on a Windows x64 build there are hundreds of warnings about 
truncating size_t to uint32_t and the possible loss of data.

-Chuck

- "Robbie Gemmell"  wrote:

> From: "Robbie Gemmell" 
> To: dev@qpid.apache.org
> Sent: Sunday, November 14, 2010 5:22:39 PM GMT -05:00 US/Canada Eastern
> Subject: Qpid 0.8 RC2 available for download ** Please Test **
>
> Hi all,
> 
> Qpid 0.8 RC2 can nowbe found for download at:
> http://people.apache.org/~robbie/qpid/0.8/RC2/
> 
> There were no changes from the output for RC1, but the output from
> running
> RAT across the 'full release' RC2 archive can be found at the
> following URL:
> http://people.apache.org/~robbie/qpid/0.8/0.8rc2_rat_output.txt
> 
> *Please* take the time to download and try out this release candidate
> and
> report your results, such that any additional issues which require
> addressing before the release can proceed are identified as early as
> possible. If no issues are reported that require a new RC to be
> produced,
> RC2 will be taken to vote by the end of the week.
> 
> Thanks,
> Robbie
> 
> For the record, the changes since RC1 are:
> 
> - QPID-2674: prevent heartbeats causing segmentation faults
> - QPID-2940: clean up message-accept records automatically
> - QPID-2941: fix error in recovery handling for new CLFS store
> - QPID-2942: enable the Java broker convenience package to be started
> out-of-the-box
> - QPID-2943: add the examples to the Java client convenience package
> - QPID-2946: exclude the QMan convenience package from the release
> (due to
> QPID-2945)
> - Update to always include cluster scripts in the C++ distribution
> regardless of dependency install status on the build box
> 
> 
> -
> 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-2950) DerbyMessageStore incorrectly logs an error for an expected exception indicating successfull database shutdown

2010-11-16 Thread Robbie Gemmell (JIRA)
DerbyMessageStore incorrectly logs an error for an expected exception 
indicating successfull database shutdown
--

 Key: QPID-2950
 URL: https://issues.apache.org/jira/browse/QPID-2950
 Project: Qpid
  Issue Type: Bug
  Components: Java Broker MessageStore - DerbyStore
Affects Versions: 0.7
Reporter: Robbie Gemmell
Assignee: Robbie Gemmell
 Fix For: 0.8


The DerbyMessageStore incorrectly logs an error for an expected exception 
indicating successfull database shutdown, because it is actuall checking for 
the wrong SQLcode for the expected exception. The value being checked currently 
is that to indicate complete shutdown of the Derby engine, and not simply the 
database being closed. 

Updating SLF4J library (QPID-2947) causes this defect to make the AlertingTest 
fail under the 'java' test profile, because the error message is then found in 
the startup logs of the external broker (due to use of an InVM broker to load 
some configuration during setup before starting the external broker) and this 
is then assumed to indicate the external broker failed to start. it is not 
clear why upgrading SLF4J causes this change in behaviour though as it would 
seem it shouldnt really impact the affected codepath; it doesnt use SLF4J and 
should already be logging the same error in the same place and so fail in the 
same way, but doesnt seem to do so.

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


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



[jira] Updated: (QPID-2947) use a newer sl4j-api release to allow the Java client binary convenience package to be used out-of-the-box

2010-11-16 Thread Robbie Gemmell (JIRA)

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

Robbie Gemmell updated QPID-2947:
-

Status: Ready To Review  (was: In Progress)

> use a newer sl4j-api release to allow the Java client binary convenience 
> package to be used out-of-the-box
> --
>
> Key: QPID-2947
> URL: https://issues.apache.org/jira/browse/QPID-2947
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Client
>Affects Versions: 0.8
>Reporter: Robbie Gemmell
>Assignee: Robbie Gemmell
> Fix For: 0.9
>
>
> New versions of slf4j-api do not throw an exception if no binding is provided 
> to a logging configuration, instead outputting a warning and defaulting to No 
> Op logging. This would allow the Java client to be used of the box without 
> forcing users to download a binding by themselves before being able to start 
> using the client (eg to run the examples).

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


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



[jira] Updated: (QPID-2950) DerbyMessageStore incorrectly logs an error for an expected exception indicating successfull database shutdown

2010-11-16 Thread Robbie Gemmell (JIRA)

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

Robbie Gemmell updated QPID-2950:
-

Status: Ready To Review  (was: In Progress)

> DerbyMessageStore incorrectly logs an error for an expected exception 
> indicating successfull database shutdown
> --
>
> Key: QPID-2950
> URL: https://issues.apache.org/jira/browse/QPID-2950
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker MessageStore - DerbyStore
>Affects Versions: 0.7
>Reporter: Robbie Gemmell
>Assignee: Robbie Gemmell
> Fix For: 0.8
>
>
> The DerbyMessageStore incorrectly logs an error for an expected exception 
> indicating successfull database shutdown, because it is actuall checking for 
> the wrong SQLcode for the expected exception. The value being checked 
> currently is that to indicate complete shutdown of the Derby engine, and not 
> simply the database being closed. 
> Updating SLF4J library (QPID-2947) causes this defect to make the 
> AlertingTest fail under the 'java' test profile, because the error message is 
> then found in the startup logs of the external broker (due to use of an InVM 
> broker to load some configuration during setup before starting the external 
> broker) and this is then assumed to indicate the external broker failed to 
> start. it is not clear why upgrading SLF4J causes this change in behaviour 
> though as it would seem it shouldnt really impact the affected codepath; it 
> doesnt use SLF4J and should already be logging the same error in the same 
> place and so fail in the same way, but doesnt seem to do so.

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


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