You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Thomas Neidhart <th...@gmail.com> on 2013/03/07 19:49:21 UTC
[CANCEL][VOTE] Release of Commons Logging 1.1.2 based on RC1
On 03/05/2013 11:08 PM, Thomas Neidhart wrote:
> Hi,
>
> I'd like to call a vote for releasing Commons Logging 1.1.2 based on RC1.
>
> This release candidate has the following changes compared to 1.1.1
> (copied from the release notes):
>
> Fixed Bugs:
> o LOGGING-124: The jar manifest now contains proper OSGi-related
> metadata information.
> o LOGGING-144: LogFactory and LogFactoryImpl will not swallow certain
> errors anymore (ThreadDeath and VirtualMachineError).
> o LOGGING-132: Jdk14Logger now correctly uses the specified logger name.
> o LOGGING-146: Properly synchronize access to protected static field
> LogFactory.nullClassLoaderFactory.
> o LOGGING-119: Prevent potential deadlock scenario in WeakHashtable.
> o LOGGING-130: Potential missing privileged block for class loader.
> o LOGGING-145: LogFactoryImpl.setAttribute - possible NPE.
> o LOGGING-142: Log4JLogger uses deprecated static members of Priority
> such as INFO.
> o LOGGING-128: Static analysis suggests a number of potential improvements.
> o LOGGING-147: SimpleLog.log - unsafe update of shortLogName.
> o LOGGING-148: LogFactory.diagnosticPrefix and diagnosticsStream could
> be final.
>
> Changes:
> o LOGGING-135: Improved thread-safety for several log adapters,
> including AvalonLogger, SimpleLog, Log4JLogger, LogKitLogger.
> o LOGGING-138: In case of a discovery failure now also the stacktrace
> of the cause will be added to the diagnostic message.
> o LOGGING-133: Change scope of Jdk14Logger.log(Level, String,
> Throwable) to protected, allowing subclasses to modify the logging output.
>
> The files:
>
> The artifacts are deployed to Nexus:
> https://repository.apache.org/content/repositories/orgapachecommons-333/commons-logging/commons-logging/1.1.2/
>
> The tag:
> https://svn.apache.org/repos/asf/commons/proper/logging/tags/LOGGING_1_1_2_RC1/
>
> The site:
> http://people.apache.org/builds/commons/logging/1.1.2/RC1/
>
> Additional Notes:
>
> o the download page and api links to older releases only work on
> the published site and will be corrected after release.
>
> Please take a look at the commons-logging-1.1.2 artifacts and vote!
>
> ------------------------------------------------
> [ ] +1 release it.
> [ ] +0 go ahead; I don't care.
> [ ] -0 there are a few minor glitches: ...
> [ ] -1 no, do not release it because ...
> ------------------------------------------------
This message cancels the vote, the following problems have been found:
a) source/binary distribution not deployed
b) WeakHashtableTestCase takes a long time with IBM JDK
ad a)
the binary assembly descriptor contains the following:
<includeSiteDirectory>true</includeSiteDirectory>
which requires the site to be built to create the assemblies.
Commenting this out, and calling:
mvn clean assembly:assembly deploy -Ptest-deploy
creates them correctly, but they are not in the target/deploy folder,
needs further investigation.
ad b)
the mentioned test case has the following code at the end:
// some JVMs seem to take a little time to put references on
// the reference queue once the reference has been collected
// need to think about whether this is enough to justify
// stepping through the collection each time...
while(testQueue.poll() == null) {}
with IBM JDK 6 this takes a very long time, even when forcing a GC from
e.g. jconsole. Also needs further investigation, refactor the test code.
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [CANCEL][VOTE] Release of Commons Logging 1.1.2 based on RC1
Posted by Thomas Neidhart <th...@gmail.com>.
On 03/08/2013 11:34 PM, sebb wrote:
> On 8 March 2013 20:28, sebb <se...@gmail.com> wrote:
>> On 8 March 2013 07:31, Thomas Neidhart <th...@gmail.com> wrote:
>>> On 03/08/2013 01:25 AM, sebb wrote:
>>>> On 7 March 2013 18:49, Thomas Neidhart <th...@gmail.com> wrote:
>>>>> On 03/05/2013 11:08 PM, Thomas Neidhart wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I'd like to call a vote for releasing Commons Logging 1.1.2 based on RC1.
>>>>>>
>>>>>> This release candidate has the following changes compared to 1.1.1
>>>>>> (copied from the release notes):
>>>>>>
>>>>>> Fixed Bugs:
>>>>>> o LOGGING-124: The jar manifest now contains proper OSGi-related
>>>>>> metadata information.
>>>>>> o LOGGING-144: LogFactory and LogFactoryImpl will not swallow certain
>>>>>> errors anymore (ThreadDeath and VirtualMachineError).
>>>>>> o LOGGING-132: Jdk14Logger now correctly uses the specified logger name.
>>>>>> o LOGGING-146: Properly synchronize access to protected static field
>>>>>> LogFactory.nullClassLoaderFactory.
>>>>>> o LOGGING-119: Prevent potential deadlock scenario in WeakHashtable.
>>>>>> o LOGGING-130: Potential missing privileged block for class loader.
>>>>>> o LOGGING-145: LogFactoryImpl.setAttribute - possible NPE.
>>>>>> o LOGGING-142: Log4JLogger uses deprecated static members of Priority
>>>>>> such as INFO.
>>>>>> o LOGGING-128: Static analysis suggests a number of potential improvements.
>>>>>> o LOGGING-147: SimpleLog.log - unsafe update of shortLogName.
>>>>>> o LOGGING-148: LogFactory.diagnosticPrefix and diagnosticsStream could
>>>>>> be final.
>>>>>>
>>>>>> Changes:
>>>>>> o LOGGING-135: Improved thread-safety for several log adapters,
>>>>>> including AvalonLogger, SimpleLog, Log4JLogger, LogKitLogger.
>>>>>> o LOGGING-138: In case of a discovery failure now also the stacktrace
>>>>>> of the cause will be added to the diagnostic message.
>>>>>> o LOGGING-133: Change scope of Jdk14Logger.log(Level, String,
>>>>>> Throwable) to protected, allowing subclasses to modify the logging output.
>>>>>>
>>>>>> The files:
>>>>>>
>>>>>> The artifacts are deployed to Nexus:
>>>>>> https://repository.apache.org/content/repositories/orgapachecommons-333/commons-logging/commons-logging/1.1.2/
>>>>>>
>>>>>> The tag:
>>>>>> https://svn.apache.org/repos/asf/commons/proper/logging/tags/LOGGING_1_1_2_RC1/
>>>>>>
>>>>>> The site:
>>>>>> http://people.apache.org/builds/commons/logging/1.1.2/RC1/
>>>>>>
>>>>>> Additional Notes:
>>>>>>
>>>>>> o the download page and api links to older releases only work on
>>>>>> the published site and will be corrected after release.
>>>>>>
>>>>>> Please take a look at the commons-logging-1.1.2 artifacts and vote!
>>>>>>
>>>>>> ------------------------------------------------
>>>>>> [ ] +1 release it.
>>>>>> [ ] +0 go ahead; I don't care.
>>>>>> [ ] -0 there are a few minor glitches: ...
>>>>>> [ ] -1 no, do not release it because ...
>>>>>> ------------------------------------------------
>>>>>
>>>>> This message cancels the vote, the following problems have been found:
>>>>>
>>>>> a) source/binary distribution not deployed
>>>>> b) WeakHashtableTestCase takes a long time with IBM JDK
>>>>>
>>>>> ad a)
>>>>>
>>>>> the binary assembly descriptor contains the following:
>>>>>
>>>>> <includeSiteDirectory>true</includeSiteDirectory>
>>>>>
>>>>> which requires the site to be built to create the assemblies.
>>>>> Commenting this out, and calling:
>>>>>
>>>>> mvn clean assembly:assembly deploy -Ptest-deploy
>>>>>
>>>>> creates them correctly, but they are not in the target/deploy folder,
>>>>> needs further investigation.
>>>>
>>>> Might also need -Prelease
>>>
>>> argh, the pom.xml for logging re-defines the release profile.
>>
>> That's not the only override it uses; there are quite a few other bits
>> that could / should probably be dropped.
>>
>>> This solved the problem that even with -Ptest-deploy the artifacts were
>>> uploaded to nexus. The assemblies are still not there.
>>
>> The assemblies are not there because of the last line below:
>>
>> <artifactId>maven-assembly-plugin</artifactId>
>> <configuration>
>> <!-- Do not deploy the assemblies to the repository. -->
>> <attach>false</attach>
>>
>> I've been playing with dropping various bits of the pom overrides, but
>> so far have not got a fully working one.
>>
>> I would expect to be able to drop the assembly plugin from logging pom
>> (as the parent one is similar), but then I get
>>
>> "Error reading assemblies: No assembly descriptors found."
>>
>> even if I move the assemblies to the standard location - i.e. src/main/assembly
>>
>> Not sure what's happening yet.
>
> Looks like one still has to provide the descriptor - other components do.
>
> Should probably consider adding it to the parent POM; that would
> simplify the component POMs
I checked in a cleaned up version that works for me locally.
The deploy directory afterwards contains all artifacts.
Could you cross-check please?
Thanks,
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [CANCEL][VOTE] Release of Commons Logging 1.1.2 based on RC1
Posted by sebb <se...@gmail.com>.
On 8 March 2013 20:28, sebb <se...@gmail.com> wrote:
> On 8 March 2013 07:31, Thomas Neidhart <th...@gmail.com> wrote:
>> On 03/08/2013 01:25 AM, sebb wrote:
>>> On 7 March 2013 18:49, Thomas Neidhart <th...@gmail.com> wrote:
>>>> On 03/05/2013 11:08 PM, Thomas Neidhart wrote:
>>>>> Hi,
>>>>>
>>>>> I'd like to call a vote for releasing Commons Logging 1.1.2 based on RC1.
>>>>>
>>>>> This release candidate has the following changes compared to 1.1.1
>>>>> (copied from the release notes):
>>>>>
>>>>> Fixed Bugs:
>>>>> o LOGGING-124: The jar manifest now contains proper OSGi-related
>>>>> metadata information.
>>>>> o LOGGING-144: LogFactory and LogFactoryImpl will not swallow certain
>>>>> errors anymore (ThreadDeath and VirtualMachineError).
>>>>> o LOGGING-132: Jdk14Logger now correctly uses the specified logger name.
>>>>> o LOGGING-146: Properly synchronize access to protected static field
>>>>> LogFactory.nullClassLoaderFactory.
>>>>> o LOGGING-119: Prevent potential deadlock scenario in WeakHashtable.
>>>>> o LOGGING-130: Potential missing privileged block for class loader.
>>>>> o LOGGING-145: LogFactoryImpl.setAttribute - possible NPE.
>>>>> o LOGGING-142: Log4JLogger uses deprecated static members of Priority
>>>>> such as INFO.
>>>>> o LOGGING-128: Static analysis suggests a number of potential improvements.
>>>>> o LOGGING-147: SimpleLog.log - unsafe update of shortLogName.
>>>>> o LOGGING-148: LogFactory.diagnosticPrefix and diagnosticsStream could
>>>>> be final.
>>>>>
>>>>> Changes:
>>>>> o LOGGING-135: Improved thread-safety for several log adapters,
>>>>> including AvalonLogger, SimpleLog, Log4JLogger, LogKitLogger.
>>>>> o LOGGING-138: In case of a discovery failure now also the stacktrace
>>>>> of the cause will be added to the diagnostic message.
>>>>> o LOGGING-133: Change scope of Jdk14Logger.log(Level, String,
>>>>> Throwable) to protected, allowing subclasses to modify the logging output.
>>>>>
>>>>> The files:
>>>>>
>>>>> The artifacts are deployed to Nexus:
>>>>> https://repository.apache.org/content/repositories/orgapachecommons-333/commons-logging/commons-logging/1.1.2/
>>>>>
>>>>> The tag:
>>>>> https://svn.apache.org/repos/asf/commons/proper/logging/tags/LOGGING_1_1_2_RC1/
>>>>>
>>>>> The site:
>>>>> http://people.apache.org/builds/commons/logging/1.1.2/RC1/
>>>>>
>>>>> Additional Notes:
>>>>>
>>>>> o the download page and api links to older releases only work on
>>>>> the published site and will be corrected after release.
>>>>>
>>>>> Please take a look at the commons-logging-1.1.2 artifacts and vote!
>>>>>
>>>>> ------------------------------------------------
>>>>> [ ] +1 release it.
>>>>> [ ] +0 go ahead; I don't care.
>>>>> [ ] -0 there are a few minor glitches: ...
>>>>> [ ] -1 no, do not release it because ...
>>>>> ------------------------------------------------
>>>>
>>>> This message cancels the vote, the following problems have been found:
>>>>
>>>> a) source/binary distribution not deployed
>>>> b) WeakHashtableTestCase takes a long time with IBM JDK
>>>>
>>>> ad a)
>>>>
>>>> the binary assembly descriptor contains the following:
>>>>
>>>> <includeSiteDirectory>true</includeSiteDirectory>
>>>>
>>>> which requires the site to be built to create the assemblies.
>>>> Commenting this out, and calling:
>>>>
>>>> mvn clean assembly:assembly deploy -Ptest-deploy
>>>>
>>>> creates them correctly, but they are not in the target/deploy folder,
>>>> needs further investigation.
>>>
>>> Might also need -Prelease
>>
>> argh, the pom.xml for logging re-defines the release profile.
>
> That's not the only override it uses; there are quite a few other bits
> that could / should probably be dropped.
>
>> This solved the problem that even with -Ptest-deploy the artifacts were
>> uploaded to nexus. The assemblies are still not there.
>
> The assemblies are not there because of the last line below:
>
> <artifactId>maven-assembly-plugin</artifactId>
> <configuration>
> <!-- Do not deploy the assemblies to the repository. -->
> <attach>false</attach>
>
> I've been playing with dropping various bits of the pom overrides, but
> so far have not got a fully working one.
>
> I would expect to be able to drop the assembly plugin from logging pom
> (as the parent one is similar), but then I get
>
> "Error reading assemblies: No assembly descriptors found."
>
> even if I move the assemblies to the standard location - i.e. src/main/assembly
>
> Not sure what's happening yet.
Looks like one still has to provide the descriptor - other components do.
Should probably consider adding it to the parent POM; that would
simplify the component POMs
>> Thomas
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [CANCEL][VOTE] Release of Commons Logging 1.1.2 based on RC1
Posted by sebb <se...@gmail.com>.
On 8 March 2013 07:31, Thomas Neidhart <th...@gmail.com> wrote:
> On 03/08/2013 01:25 AM, sebb wrote:
>> On 7 March 2013 18:49, Thomas Neidhart <th...@gmail.com> wrote:
>>> On 03/05/2013 11:08 PM, Thomas Neidhart wrote:
>>>> Hi,
>>>>
>>>> I'd like to call a vote for releasing Commons Logging 1.1.2 based on RC1.
>>>>
>>>> This release candidate has the following changes compared to 1.1.1
>>>> (copied from the release notes):
>>>>
>>>> Fixed Bugs:
>>>> o LOGGING-124: The jar manifest now contains proper OSGi-related
>>>> metadata information.
>>>> o LOGGING-144: LogFactory and LogFactoryImpl will not swallow certain
>>>> errors anymore (ThreadDeath and VirtualMachineError).
>>>> o LOGGING-132: Jdk14Logger now correctly uses the specified logger name.
>>>> o LOGGING-146: Properly synchronize access to protected static field
>>>> LogFactory.nullClassLoaderFactory.
>>>> o LOGGING-119: Prevent potential deadlock scenario in WeakHashtable.
>>>> o LOGGING-130: Potential missing privileged block for class loader.
>>>> o LOGGING-145: LogFactoryImpl.setAttribute - possible NPE.
>>>> o LOGGING-142: Log4JLogger uses deprecated static members of Priority
>>>> such as INFO.
>>>> o LOGGING-128: Static analysis suggests a number of potential improvements.
>>>> o LOGGING-147: SimpleLog.log - unsafe update of shortLogName.
>>>> o LOGGING-148: LogFactory.diagnosticPrefix and diagnosticsStream could
>>>> be final.
>>>>
>>>> Changes:
>>>> o LOGGING-135: Improved thread-safety for several log adapters,
>>>> including AvalonLogger, SimpleLog, Log4JLogger, LogKitLogger.
>>>> o LOGGING-138: In case of a discovery failure now also the stacktrace
>>>> of the cause will be added to the diagnostic message.
>>>> o LOGGING-133: Change scope of Jdk14Logger.log(Level, String,
>>>> Throwable) to protected, allowing subclasses to modify the logging output.
>>>>
>>>> The files:
>>>>
>>>> The artifacts are deployed to Nexus:
>>>> https://repository.apache.org/content/repositories/orgapachecommons-333/commons-logging/commons-logging/1.1.2/
>>>>
>>>> The tag:
>>>> https://svn.apache.org/repos/asf/commons/proper/logging/tags/LOGGING_1_1_2_RC1/
>>>>
>>>> The site:
>>>> http://people.apache.org/builds/commons/logging/1.1.2/RC1/
>>>>
>>>> Additional Notes:
>>>>
>>>> o the download page and api links to older releases only work on
>>>> the published site and will be corrected after release.
>>>>
>>>> Please take a look at the commons-logging-1.1.2 artifacts and vote!
>>>>
>>>> ------------------------------------------------
>>>> [ ] +1 release it.
>>>> [ ] +0 go ahead; I don't care.
>>>> [ ] -0 there are a few minor glitches: ...
>>>> [ ] -1 no, do not release it because ...
>>>> ------------------------------------------------
>>>
>>> This message cancels the vote, the following problems have been found:
>>>
>>> a) source/binary distribution not deployed
>>> b) WeakHashtableTestCase takes a long time with IBM JDK
>>>
>>> ad a)
>>>
>>> the binary assembly descriptor contains the following:
>>>
>>> <includeSiteDirectory>true</includeSiteDirectory>
>>>
>>> which requires the site to be built to create the assemblies.
>>> Commenting this out, and calling:
>>>
>>> mvn clean assembly:assembly deploy -Ptest-deploy
>>>
>>> creates them correctly, but they are not in the target/deploy folder,
>>> needs further investigation.
>>
>> Might also need -Prelease
>
> argh, the pom.xml for logging re-defines the release profile.
That's not the only override it uses; there are quite a few other bits
that could / should probably be dropped.
> This solved the problem that even with -Ptest-deploy the artifacts were
> uploaded to nexus. The assemblies are still not there.
The assemblies are not there because of the last line below:
<artifactId>maven-assembly-plugin</artifactId>
<configuration>
<!-- Do not deploy the assemblies to the repository. -->
<attach>false</attach>
I've been playing with dropping various bits of the pom overrides, but
so far have not got a fully working one.
I would expect to be able to drop the assembly plugin from logging pom
(as the parent one is similar), but then I get
"Error reading assemblies: No assembly descriptors found."
even if I move the assemblies to the standard location - i.e. src/main/assembly
Not sure what's happening yet.
> Thomas
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [CANCEL][VOTE] Release of Commons Logging 1.1.2 based on RC1
Posted by Thomas Neidhart <th...@gmail.com>.
On 03/08/2013 01:25 AM, sebb wrote:
> On 7 March 2013 18:49, Thomas Neidhart <th...@gmail.com> wrote:
>> On 03/05/2013 11:08 PM, Thomas Neidhart wrote:
>>> Hi,
>>>
>>> I'd like to call a vote for releasing Commons Logging 1.1.2 based on RC1.
>>>
>>> This release candidate has the following changes compared to 1.1.1
>>> (copied from the release notes):
>>>
>>> Fixed Bugs:
>>> o LOGGING-124: The jar manifest now contains proper OSGi-related
>>> metadata information.
>>> o LOGGING-144: LogFactory and LogFactoryImpl will not swallow certain
>>> errors anymore (ThreadDeath and VirtualMachineError).
>>> o LOGGING-132: Jdk14Logger now correctly uses the specified logger name.
>>> o LOGGING-146: Properly synchronize access to protected static field
>>> LogFactory.nullClassLoaderFactory.
>>> o LOGGING-119: Prevent potential deadlock scenario in WeakHashtable.
>>> o LOGGING-130: Potential missing privileged block for class loader.
>>> o LOGGING-145: LogFactoryImpl.setAttribute - possible NPE.
>>> o LOGGING-142: Log4JLogger uses deprecated static members of Priority
>>> such as INFO.
>>> o LOGGING-128: Static analysis suggests a number of potential improvements.
>>> o LOGGING-147: SimpleLog.log - unsafe update of shortLogName.
>>> o LOGGING-148: LogFactory.diagnosticPrefix and diagnosticsStream could
>>> be final.
>>>
>>> Changes:
>>> o LOGGING-135: Improved thread-safety for several log adapters,
>>> including AvalonLogger, SimpleLog, Log4JLogger, LogKitLogger.
>>> o LOGGING-138: In case of a discovery failure now also the stacktrace
>>> of the cause will be added to the diagnostic message.
>>> o LOGGING-133: Change scope of Jdk14Logger.log(Level, String,
>>> Throwable) to protected, allowing subclasses to modify the logging output.
>>>
>>> The files:
>>>
>>> The artifacts are deployed to Nexus:
>>> https://repository.apache.org/content/repositories/orgapachecommons-333/commons-logging/commons-logging/1.1.2/
>>>
>>> The tag:
>>> https://svn.apache.org/repos/asf/commons/proper/logging/tags/LOGGING_1_1_2_RC1/
>>>
>>> The site:
>>> http://people.apache.org/builds/commons/logging/1.1.2/RC1/
>>>
>>> Additional Notes:
>>>
>>> o the download page and api links to older releases only work on
>>> the published site and will be corrected after release.
>>>
>>> Please take a look at the commons-logging-1.1.2 artifacts and vote!
>>>
>>> ------------------------------------------------
>>> [ ] +1 release it.
>>> [ ] +0 go ahead; I don't care.
>>> [ ] -0 there are a few minor glitches: ...
>>> [ ] -1 no, do not release it because ...
>>> ------------------------------------------------
>>
>> This message cancels the vote, the following problems have been found:
>>
>> a) source/binary distribution not deployed
>> b) WeakHashtableTestCase takes a long time with IBM JDK
>>
>> ad a)
>>
>> the binary assembly descriptor contains the following:
>>
>> <includeSiteDirectory>true</includeSiteDirectory>
>>
>> which requires the site to be built to create the assemblies.
>> Commenting this out, and calling:
>>
>> mvn clean assembly:assembly deploy -Ptest-deploy
>>
>> creates them correctly, but they are not in the target/deploy folder,
>> needs further investigation.
>
> Might also need -Prelease
argh, the pom.xml for logging re-defines the release profile.
This solved the problem that even with -Ptest-deploy the artifacts were
uploaded to nexus. The assemblies are still not there.
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [CANCEL][VOTE] Release of Commons Logging 1.1.2 based on RC1
Posted by sebb <se...@gmail.com>.
On 7 March 2013 18:49, Thomas Neidhart <th...@gmail.com> wrote:
> On 03/05/2013 11:08 PM, Thomas Neidhart wrote:
>> Hi,
>>
>> I'd like to call a vote for releasing Commons Logging 1.1.2 based on RC1.
>>
>> This release candidate has the following changes compared to 1.1.1
>> (copied from the release notes):
>>
>> Fixed Bugs:
>> o LOGGING-124: The jar manifest now contains proper OSGi-related
>> metadata information.
>> o LOGGING-144: LogFactory and LogFactoryImpl will not swallow certain
>> errors anymore (ThreadDeath and VirtualMachineError).
>> o LOGGING-132: Jdk14Logger now correctly uses the specified logger name.
>> o LOGGING-146: Properly synchronize access to protected static field
>> LogFactory.nullClassLoaderFactory.
>> o LOGGING-119: Prevent potential deadlock scenario in WeakHashtable.
>> o LOGGING-130: Potential missing privileged block for class loader.
>> o LOGGING-145: LogFactoryImpl.setAttribute - possible NPE.
>> o LOGGING-142: Log4JLogger uses deprecated static members of Priority
>> such as INFO.
>> o LOGGING-128: Static analysis suggests a number of potential improvements.
>> o LOGGING-147: SimpleLog.log - unsafe update of shortLogName.
>> o LOGGING-148: LogFactory.diagnosticPrefix and diagnosticsStream could
>> be final.
>>
>> Changes:
>> o LOGGING-135: Improved thread-safety for several log adapters,
>> including AvalonLogger, SimpleLog, Log4JLogger, LogKitLogger.
>> o LOGGING-138: In case of a discovery failure now also the stacktrace
>> of the cause will be added to the diagnostic message.
>> o LOGGING-133: Change scope of Jdk14Logger.log(Level, String,
>> Throwable) to protected, allowing subclasses to modify the logging output.
>>
>> The files:
>>
>> The artifacts are deployed to Nexus:
>> https://repository.apache.org/content/repositories/orgapachecommons-333/commons-logging/commons-logging/1.1.2/
>>
>> The tag:
>> https://svn.apache.org/repos/asf/commons/proper/logging/tags/LOGGING_1_1_2_RC1/
>>
>> The site:
>> http://people.apache.org/builds/commons/logging/1.1.2/RC1/
>>
>> Additional Notes:
>>
>> o the download page and api links to older releases only work on
>> the published site and will be corrected after release.
>>
>> Please take a look at the commons-logging-1.1.2 artifacts and vote!
>>
>> ------------------------------------------------
>> [ ] +1 release it.
>> [ ] +0 go ahead; I don't care.
>> [ ] -0 there are a few minor glitches: ...
>> [ ] -1 no, do not release it because ...
>> ------------------------------------------------
>
> This message cancels the vote, the following problems have been found:
>
> a) source/binary distribution not deployed
> b) WeakHashtableTestCase takes a long time with IBM JDK
>
> ad a)
>
> the binary assembly descriptor contains the following:
>
> <includeSiteDirectory>true</includeSiteDirectory>
>
> which requires the site to be built to create the assemblies.
> Commenting this out, and calling:
>
> mvn clean assembly:assembly deploy -Ptest-deploy
>
> creates them correctly, but they are not in the target/deploy folder,
> needs further investigation.
Might also need -Prelease
> ad b)
>
> the mentioned test case has the following code at the end:
>
> // some JVMs seem to take a little time to put references on
> // the reference queue once the reference has been collected
> // need to think about whether this is enough to justify
> // stepping through the collection each time...
> while(testQueue.poll() == null) {}
>
> with IBM JDK 6 this takes a very long time, even when forcing a GC from
> e.g. jconsole. Also needs further investigation, refactor the test code.
>
> Thomas
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org