Re: [LANG] EqualsBuilder#reflectionEquals feature brainstorming

[Mark Struberg]

Tbh, I was really surprised to find out that in Java8 the code did indeed also 
introspect internal fields of all those java.util.* foundation classes. It's 
imo pure luck that it did work so well for a decade for anything Set, List, 
Map, etc.

Working on a patch with all those discussed changes.

LieGrue,
strub


> Am 08.03.2024 um 13:19 schrieb Gary Gregory :
> 
> The next question is whether any of this should be mentioned/recorded in
> the Javadoc or at least in a code comment.
> 
> Gary
> 
> On Fri, Mar 8, 2024, 5:24 AM Mark Struberg 
> wrote:
> 
>> Hi Gary!
>> 
>> Yes, this would be really slow. Plus after further thinking about it, I
>> guess it doesn't add anything over the required existing behaviour imo.
>> Until now reflectionEquals did simply dig into the Class.getDeclaredFields
>> of those java.util.* classes. So it only did compare the EXAKT same
>> situations. having differences in internal hash codes or whatever would
>> result in detecting a difference. So probably just iterating over the
>> entries is perfectly fine for now.
>> Same for Maps. Not sure though, whether we should just iterate over the
>> entries and compare those, or do a map lookup (which would require equals
>> again).
>> 
>> Btw, I thought again about the 'customEquals' part. Maybe we cannot rely
>> on it fully, means if it returns false it doesn't mean they are really
>> different. Otoh IF it returns true, then we can take it for granted, that
>> those two are the same. And further thinking about it: what if we *always*
>> invoke equals() first, and if it returns true -> return true and skip the
>> rest for this tree?
>> 
>> LieGrue,
>> strub
>> 
>> 
>>> Am 07.03.2024 um 14:55 schrieb Gary D. Gregory :
>>> 
>>> On 2024/03/07 06:58:30 Mark Struberg wrote:
>>>> The question to me is how we can make it more robust.
>>>> In a Collection (but actually also in most lists) the order in which
>> you get the values (Iterator or get(i)) is not deterministic. It can be
>> different in one list than in another - even if they contain the exact same
>> items.
>>> 
>>> Hm, so to iterate through Lists in parallel would work but not with Sets.
>>> 
>>>> 
>>>> Not yet sure how to work around this. We can probably try to sort it
>> first, but then again, if they do not implement Comparable it won't help
>> much. Or do a containsElement based on reflection as well - but that would
>> be rather slow.
>>> 
>>> This is one of those: If you want support for the feature, it'll work,
>> but it'll be slow because there is no other way to do it (for now if ever).
>>> 
>>> Gary
>>> 
>>>> 
>>>> Same with Maps. There is a good reason why the key at least should
>> implement equals/hashCode. If this is not the case, then we are not able to
>> implement this properly I fear.
>>>> 
>>>> Any ideas?
>>>> 
>>>> LieGrue,
>>>> strub
>>>> 
>>>>> Am 06.03.2024 um 15:53 schrieb Gary Gregory :
>>>>> 
>>>>> Ah, right, custom "non-equalable" _inside_ Collections and Maps...
>>>>> 
>>>>> For the diff, I'd suggest you test and iterable over a Collection
>>>>> instead of a List.
>>>>> 
>>>>> Then you'd need a separate test and traversal for Map instances.
>>>>> 
>>>>> (Still no common super-interface in Java 21 for Collections and
>> Maps...)
>>>>> 
>>>>> Gary
>>>>> 
>>>>> On Wed, Mar 6, 2024 at 7:40 AM Mark Struberg 
>> wrote:
>>>>>> 
>>>>>> Hi Gregory!
>>>>>> 
>>>>>> I did try this out and figured that I didn't think it though. Maybe I
>> need to go a few steps back and explain the problem:
>>>>>> 
>>>>>> I have the following constellation
>>>>>> 
>>>>>> public class SomeInnerDTO {int field..} // NOT implements equals!
>>>>>> public class TheOuterDTO{ List innerList;..}
>>>>>> 
>>>>>> My problem is that reflectionEquals (which I use in a unit test)
>> tries to introspect fields even in java.util.classes. And for getting the
>> values of those classes it tries to call a setAccessible(true);
>>>>>> And obviously here it fails. There is a ticket already open [1] which
>> sugggests to use trySetAccessible. But I fear that will s

Re: [LANG] EqualsBuilder#reflectionEquals feature brainstorming

[Mark Struberg]

Hi Daniel!

Yes, you are right. As written in my mail to Gary: I think it would be enough 
for now if we'd come to the same results as before the module privacy 
restrictions. If we do better later on it is an optional bonus.

LieGrue,
strub


> Am 07.03.2024 um 15:39 schrieb Daniel Watson :
> 
> One comment about the collection comparison...
> 
> For any collection that actually implements List, equality should *include*
> order, not attempt to ignore it, right? The contract of a list is that the
> order is consistent, and two lists with the same items in different order,
> should not be considered equal.
> 
> e.g for List:
> 
> Best case scenario - The lengths are different and you dont have to check
> any equalities
> Worst case scenario - every item is equal and you have to iterate both
> lists completely
> Remaining Cases  - Item [i] is different and you dont have to check
> anything past that
> 
> (For pretty much any collection I think the best case is the same)
> 
> For sets, maybe it could be optimized by creating a new collection and
> removing items as you find them, so each step necessarily gets smaller? Not
> sure about this though.
> 
> 
> 
> On Thu, Mar 7, 2024 at 8:55 AM Gary D. Gregory  wrote:
> 
>> On 2024/03/07 06:58:30 Mark Struberg wrote:
>>> The question to me is how we can make it more robust.
>>> In a Collection (but actually also in most lists) the order in which you
>> get the values (Iterator or get(i)) is not deterministic. It can be
>> different in one list than in another - even if they contain the exact same
>> items.
>> 
>> Hm, so to iterate through Lists in parallel would work but not with Sets.
>> 
>>> 
>>> Not yet sure how to work around this. We can probably try to sort it
>> first, but then again, if they do not implement Comparable it won't help
>> much. Or do a containsElement based on reflection as well - but that would
>> be rather slow.
>> 
>> This is one of those: If you want support for the feature, it'll work, but
>> it'll be slow because there is no other way to do it (for now if ever).
>> 
>> Gary
>> 
>>> 
>>> Same with Maps. There is a good reason why the key at least should
>> implement equals/hashCode. If this is not the case, then we are not able to
>> implement this properly I fear.
>>> 
>>> Any ideas?
>>> 
>>> LieGrue,
>>> strub
>>> 
>>>> Am 06.03.2024 um 15:53 schrieb Gary Gregory :
>>>> 
>>>> Ah, right, custom "non-equalable" _inside_ Collections and Maps...
>>>> 
>>>> For the diff, I'd suggest you test and iterable over a Collection
>>>> instead of a List.
>>>> 
>>>> Then you'd need a separate test and traversal for Map instances.
>>>> 
>>>> (Still no common super-interface in Java 21 for Collections and
>> Maps...)
>>>> 
>>>> Gary
>>>> 
>>>> On Wed, Mar 6, 2024 at 7:40 AM Mark Struberg 
>> wrote:
>>>>> 
>>>>> Hi Gregory!
>>>>> 
>>>>> I did try this out and figured that I didn't think it though. Maybe I
>> need to go a few steps back and explain the problem:
>>>>> 
>>>>> I have the following constellation
>>>>> 
>>>>> public class SomeInnerDTO {int field..} // NOT implements equals!
>>>>> public class TheOuterDTO{ List innerList;..}
>>>>> 
>>>>> My problem is that reflectionEquals (which I use in a unit test)
>> tries to introspect fields even in java.util.classes. And for getting the
>> values of those classes it tries to call a setAccessible(true);
>>>>> And obviously here it fails. There is a ticket already open [1] which
>> sugggests to use trySetAccessible. But I fear that will still do nothing
>> and you won't get access to those inner knowledge inside
>> java.util.LinkedList etc.
>>>>> 
>>>>> And using equals() on the List sadly won't help either, as the
>> SomeInnerDTO would also get compared with equals(), but that will obviously
>> use identity comparison only :(
>>>>> 
>>>>> 
>>>>> What I did for now (running all tests with a few projects right now,
>> but looks promising):
>>>>> 
>>>>> diff --git
>> a/src/main/java/org/apache/commons/lang3/builder/EqualsBuilder.java
>> b/src/main/java/org/apache/commons/lang3/builder/EqualsBuilder.java
>>>>> index ff5276b04..cf878da40 100644
>>>>

Re: [LANG] EqualsBuilder#reflectionEquals feature brainstorming

[Mark Struberg]

Hi Gary!

Yes, this would be really slow. Plus after further thinking about it, I guess 
it doesn't add anything over the required existing behaviour imo. Until now 
reflectionEquals did simply dig into the Class.getDeclaredFields of those 
java.util.* classes. So it only did compare the EXAKT same situations. having 
differences in internal hash codes or whatever would result in detecting a 
difference. So probably just iterating over the entries is perfectly fine for 
now.
Same for Maps. Not sure though, whether we should just iterate over the entries 
and compare those, or do a map lookup (which would require equals again).

Btw, I thought again about the 'customEquals' part. Maybe we cannot rely on it 
fully, means if it returns false it doesn't mean they are really different. 
Otoh IF it returns true, then we can take it for granted, that those two are 
the same. And further thinking about it: what if we *always* invoke equals() 
first, and if it returns true -> return true and skip the rest for this tree?

LieGrue,
strub


> Am 07.03.2024 um 14:55 schrieb Gary D. Gregory :
> 
> On 2024/03/07 06:58:30 Mark Struberg wrote:
>> The question to me is how we can make it more robust.
>> In a Collection (but actually also in most lists) the order in which you get 
>> the values (Iterator or get(i)) is not deterministic. It can be different in 
>> one list than in another - even if they contain the exact same items.
> 
> Hm, so to iterate through Lists in parallel would work but not with Sets.
> 
>> 
>> Not yet sure how to work around this. We can probably try to sort it first, 
>> but then again, if they do not implement Comparable it won't help much. Or 
>> do a containsElement based on reflection as well - but that would be rather 
>> slow.
> 
> This is one of those: If you want support for the feature, it'll work, but 
> it'll be slow because there is no other way to do it (for now if ever).
> 
> Gary
> 
>> 
>> Same with Maps. There is a good reason why the key at least should implement 
>> equals/hashCode. If this is not the case, then we are not able to implement 
>> this properly I fear.
>> 
>> Any ideas?
>> 
>> LieGrue,
>> strub
>> 
>>> Am 06.03.2024 um 15:53 schrieb Gary Gregory :
>>> 
>>> Ah, right, custom "non-equalable" _inside_ Collections and Maps...
>>> 
>>> For the diff, I'd suggest you test and iterable over a Collection
>>> instead of a List.
>>> 
>>> Then you'd need a separate test and traversal for Map instances.
>>> 
>>> (Still no common super-interface in Java 21 for Collections and Maps...)
>>> 
>>> Gary
>>> 
>>> On Wed, Mar 6, 2024 at 7:40 AM Mark Struberg  
>>> wrote:
>>>> 
>>>> Hi Gregory!
>>>> 
>>>> I did try this out and figured that I didn't think it though. Maybe I need 
>>>> to go a few steps back and explain the problem:
>>>> 
>>>> I have the following constellation
>>>> 
>>>> public class SomeInnerDTO {int field..} // NOT implements equals!
>>>> public class TheOuterDTO{ List innerList;..}
>>>> 
>>>> My problem is that reflectionEquals (which I use in a unit test) tries to 
>>>> introspect fields even in java.util.classes. And for getting the values of 
>>>> those classes it tries to call a setAccessible(true);
>>>> And obviously here it fails. There is a ticket already open [1] which 
>>>> sugggests to use trySetAccessible. But I fear that will still do nothing 
>>>> and you won't get access to those inner knowledge inside 
>>>> java.util.LinkedList etc.
>>>> 
>>>> And using equals() on the List sadly won't help either, as the 
>>>> SomeInnerDTO would also get compared with equals(), but that will 
>>>> obviously use identity comparison only :(
>>>> 
>>>> 
>>>> What I did for now (running all tests with a few projects right now, but 
>>>> looks promising):
>>>> 
>>>> diff --git 
>>>> a/src/main/java/org/apache/commons/lang3/builder/EqualsBuilder.java 
>>>> b/src/main/java/org/apache/commons/lang3/builder/EqualsBuilder.java
>>>> index ff5276b04..cf878da40 100644
>>>> --- a/src/main/java/org/apache/commons/lang3/builder/EqualsBuilder.java
>>>> +++ b/src/main/java/org/apache/commons/lang3/builder/EqualsBuilder.java
>>>> @@ -978,6 +978,16 @@ public EqualsBuilder reflectionAppend(final Object 
>>>> lhs, final Object rhs) {
>>>>if (bypassReflectionC

Re: [LANG] EqualsBuilder#reflectionEquals feature brainstorming

[Mark Struberg]

The question to me is how we can make it more robust.
In a Collection (but actually also in most lists) the order in which you get 
the values (Iterator or get(i)) is not deterministic. It can be different in 
one list than in another - even if they contain the exact same items.

Not yet sure how to work around this. We can probably try to sort it first, but 
then again, if they do not implement Comparable it won't help much. Or do a 
containsElement based on reflection as well - but that would be rather slow.

Same with Maps. There is a good reason why the key at least should implement 
equals/hashCode. If this is not the case, then we are not able to implement 
this properly I fear.

Any ideas?

LieGrue,
strub

> Am 06.03.2024 um 15:53 schrieb Gary Gregory :
> 
> Ah, right, custom "non-equalable" _inside_ Collections and Maps...
> 
> For the diff, I'd suggest you test and iterable over a Collection
> instead of a List.
> 
> Then you'd need a separate test and traversal for Map instances.
> 
> (Still no common super-interface in Java 21 for Collections and Maps...)
> 
> Gary
> 
> On Wed, Mar 6, 2024 at 7:40 AM Mark Struberg  
> wrote:
>> 
>> Hi Gregory!
>> 
>> I did try this out and figured that I didn't think it though. Maybe I need 
>> to go a few steps back and explain the problem:
>> 
>> I have the following constellation
>> 
>> public class SomeInnerDTO {int field..} // NOT implements equals!
>> public class TheOuterDTO{ List innerList;..}
>> 
>> My problem is that reflectionEquals (which I use in a unit test) tries to 
>> introspect fields even in java.util.classes. And for getting the values of 
>> those classes it tries to call a setAccessible(true);
>> And obviously here it fails. There is a ticket already open [1] which 
>> sugggests to use trySetAccessible. But I fear that will still do nothing and 
>> you won't get access to those inner knowledge inside java.util.LinkedList 
>> etc.
>> 
>> And using equals() on the List sadly won't help either, as the SomeInnerDTO 
>> would also get compared with equals(), but that will obviously use identity 
>> comparison only :(
>> 
>> 
>> What I did for now (running all tests with a few projects right now, but 
>> looks promising):
>> 
>> diff --git 
>> a/src/main/java/org/apache/commons/lang3/builder/EqualsBuilder.java 
>> b/src/main/java/org/apache/commons/lang3/builder/EqualsBuilder.java
>> index ff5276b04..cf878da40 100644
>> --- a/src/main/java/org/apache/commons/lang3/builder/EqualsBuilder.java
>> +++ b/src/main/java/org/apache/commons/lang3/builder/EqualsBuilder.java
>> @@ -978,6 +978,16 @@ public EqualsBuilder reflectionAppend(final Object lhs, 
>> final Object rhs) {
>> if (bypassReflectionClasses != null
>> && (bypassReflectionClasses.contains(lhsClass) || 
>> bypassReflectionClasses.contains(rhsClass))) {
>> isEquals = lhs.equals(rhs);
>> +} else if (testClass.isAssignableFrom(List.class)) {
>> +List lList = (List) lhs;
>> +List rList = (List) rhs;
>> +if (lList.size() != rList.size()) {
>> +isEquals = false;
>> +return this;
>> +}
>> +for (int i = 0; i < lList.size(); i++) {
>> +reflectionAppend(lList.get(i), rList.get(i));
>> +}
>> } else {
>> 
>> I'm rather sure this is still not enough and there are plenty other cases to 
>> consider. Like e.g. handling Maps etc.
>> But at least that's the direction I try to approach it right now. And of 
>> course this new part should potentially also be enabled by a flag...
>> 
>> Will keep you updated.
>> 
>> txs and LieGrue,
>> strub
>> 
>> 
>> [1] https://issues.apache.org/jira/browse/LANG-1711
>> 
>>> Am 06.03.2024 um 13:18 schrieb Gary Gregory :
>>> 
>>> This sounds like a good idea to try. I would call the option something else
>>> though. We would not skip calling equals if it is defined right? How about
>>> "useEqualsIfPresent".
>>> 
>>> Gary
>>> 
>>> On Wed, Mar 6, 2024, 5:03 AM Mark Struberg 
>>> wrote:
>>> 
>>>> Hi!
>>>> 
>>>> I have a question about EqualsBuilder#reflectionEquals. From Java9 onwards
>>>> we get more and more nasty module problems. Mainly because the code tries
>>>> to recurse into java.util.* classes as well.
>>>> I know that I

Re: [LANG] EqualsBuilder#reflectionEquals feature brainstorming

[Mark Struberg]

Hi Gregory!

I did try this out and figured that I didn't think it though. Maybe I need to 
go a few steps back and explain the problem:

I have the following constellation

public class SomeInnerDTO {int field..} // NOT implements equals!
public class TheOuterDTO{ List innerList;..}

My problem is that reflectionEquals (which I use in a unit test) tries to 
introspect fields even in java.util.classes. And for getting the values of 
those classes it tries to call a setAccessible(true); 
And obviously here it fails. There is a ticket already open [1] which sugggests 
to use trySetAccessible. But I fear that will still do nothing and you won't 
get access to those inner knowledge inside java.util.LinkedList etc.

And using equals() on the List sadly won't help either, as the SomeInnerDTO 
would also get compared with equals(), but that will obviously use identity 
comparison only :(


What I did for now (running all tests with a few projects right now, but looks 
promising):

diff --git a/src/main/java/org/apache/commons/lang3/builder/EqualsBuilder.java 
b/src/main/java/org/apache/commons/lang3/builder/EqualsBuilder.java
index ff5276b04..cf878da40 100644
--- a/src/main/java/org/apache/commons/lang3/builder/EqualsBuilder.java
+++ b/src/main/java/org/apache/commons/lang3/builder/EqualsBuilder.java
@@ -978,6 +978,16 @@ public EqualsBuilder reflectionAppend(final Object lhs, 
final Object rhs) {
 if (bypassReflectionClasses != null
 && (bypassReflectionClasses.contains(lhsClass) || 
bypassReflectionClasses.contains(rhsClass))) {
 isEquals = lhs.equals(rhs);
+} else if (testClass.isAssignableFrom(List.class)) {
+List lList = (List) lhs;
+List rList = (List) rhs;
+if (lList.size() != rList.size()) {
+isEquals = false;
+return this;
+}
+for (int i = 0; i < lList.size(); i++) {
+reflectionAppend(lList.get(i), rList.get(i));
+}
 } else {

I'm rather sure this is still not enough and there are plenty other cases to 
consider. Like e.g. handling Maps etc.
But at least that's the direction I try to approach it right now. And of course 
this new part should potentially also be enabled by a flag...

Will keep you updated.

txs and LieGrue,
strub


[1] https://issues.apache.org/jira/browse/LANG-1711

> Am 06.03.2024 um 13:18 schrieb Gary Gregory :
> 
> This sounds like a good idea to try. I would call the option something else
> though. We would not skip calling equals if it is defined right? How about
> "useEqualsIfPresent".
> 
> Gary
> 
> On Wed, Mar 6, 2024, 5:03 AM Mark Struberg 
> wrote:
> 
>> Hi!
>> 
>> I have a question about EqualsBuilder#reflectionEquals. From Java9 onwards
>> we get more and more nasty module problems. Mainly because the code tries
>> to recurse into java.util.* classes as well.
>> I know that I can use setBypassReflectionClasses for those. But wouldn't
>> it be fine to have an additional switch to 'skipOnCustomEquals' or similar?
>> 
>> The idea is to only use reflection on classes which do not provide their
>> own equals method. One can test this imo rather easily by checking whether
>> classInQuestion.getMethod("equals", Object.class).getDeclaringClass() !=
>> Object.class
>> Do that for lhs and rhs and if both fit the criteria -> invoke equals
>> 
>> Wdyt of that idea? Worth trying or is there already a better solution?
>> With the new flag we can make sure that we do not change the current
>> behaviour for existing use cases.
>> 
>> LieGrue,
>> strub
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>> 
>> 


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

[LANG] EqualsBuilder#reflectionEquals feature brainstorming

[Mark Struberg]

Hi!

I have a question about EqualsBuilder#reflectionEquals. From Java9 onwards we 
get more and more nasty module problems. Mainly because the code tries to 
recurse into java.util.* classes as well.
I know that I can use setBypassReflectionClasses for those. But wouldn't it be 
fine to have an additional switch to 'skipOnCustomEquals' or similar?

The idea is to only use reflection on classes which do not provide their own 
equals method. One can test this imo rather easily by checking whether 
classInQuestion.getMethod("equals", Object.class).getDeclaringClass() != 
Object.class
Do that for lhs and rhs and if both fit the criteria -> invoke equals

Wdyt of that idea? Worth trying or is there already a better solution?
With the new flag we can make sure that we do not change the current behaviour 
for existing use cases.

LieGrue,
strub


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

Re: [EXTERNAL] [exec][email] Java 7 to 8

[Mark Struberg]

Oracle changed the license past Java8. Oracle Java is not free anymore. OpenJDK 
is though. So for anything later people have to move to AdoptOpenJDK. And 
company executives seem to be not sure about that move yet. Also the half year 
cadence leads to way less testing on a specific Java Version. Even if Java11 is 
LTS it does not see big adoption because it's only 'supported' by Oracle (main 
marketing) for half a year. Also while most of their Java Module changes in 
Java9..16 is nice for their internal decoupling it is often a major pita for 
downstream projects.

My personal guess is that Java17 (which is the next LTS) will see some 
adoption. With anything in between pretty much getting skipped, except where it 
really makes sense. e.g. Java Native Memory Access support for Apache Lucene, 
etc.

LieGrue,
strub

> Am 22.03.2021 um 19:46 schrieb Strauss, Randy (ARC-AF)[KBR Wyle Services, 
> LLC] :
> 
>> 2018-11-29-F008-Back40.csv 
> 
> I work for NASA (as a contractor).  It seems that for Macs, NASA, and perhaps 
> all of the federal government, don't yet support anything past Java 8.  I 
> have no idea why...
> -r
> Randy Strauss
> Software Engr, SWS/UAM/UTM, NASA Ames Research Center
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org


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

Re: [VOTE] [CANCEL] Release Apache Commons Pool2 2.6.1

[Mark Struberg]

Yes, not destroying the borrowed object would be an option. I didn't want to go 
down that route as there are multiple reasons why a borrowed object is not 
valid anymore.
E.g. it could be 'consumed', it could be broken, shouldn't be used do to 
maxUsageTime is over, etc. 
That's why I opted for calling create(). But of course, that has other 
potential issues :/

LieGrue,
strub


> Am 28.11.2018 um 04:21 schrieb Phil Steitz :
> 
> On 11/26/18 1:23 PM, Phil Steitz wrote:
>> On 11/26/18 8:29 AM, Phil Steitz wrote:
>>> On 11/26/18 6:19 AM, Mark Struberg wrote:
>>>> Hi Phil!
>>> 
>>> Let me start by repeating that other than trying to help diagnose bugs and 
>>> answer user questions, I don't really work on [pool] any more, so I don't 
>>> really have any standing here.  You are the RM, so it is completely up to 
>>> you and the active Commons committers to decide what to do with the code.  
>>> So fine to ignore my comments.
>>>> 
>>>> 
>>>>>   I think that the right answer here is WONT_FIX. That sounds harsh, but 
>>>>> it seems to me
>>>>> that the obvious solution here is for the user to set maxIdle to at least 
>>>>> 1.
>>>> I thought about that as well!
>>>> Setting maxIdle to 1 will make it less likely but a deadlock will STILL 
>>>> happen.
>>> I am not sure this is right.  If maxIdle >0, the fix for POOL-240 (a 
>>> similar liveness issue) should kick in and work. Each time a validation or 
>>> passivation failure occurs on return, there is a call to ensureIdle that 
>>> will create a new instance and add it to the pool if there is capacity to 
>>> do so.
>>>> So I fear we really need to tackle this. Stackoverflow and our own bug 
>>>> tracker is full of such reports :(
>>> 
>>> I see one additional actual report on GKOP (the other linked issue, which 
>>> should be similarly patched if the consensus is to do this for GOP). The 
>>> vast majority of the liveness reports that we have gotten over the years in 
>>> DBCP and pool are just pool exhausted due to failure to return instances.
>>> 
>>> The workaround violating maxIdle will restore liveness, but is likely the 
>>> wrong solution here.  Again, up to you guys to judge. Note that when you 
>>> specify maxIdle equal to 1
>> Crap.  Meant 0 there.
>>> you are telling the pool to destroy all returning instances.  To use the 
>>> pool in this way is silly, IMO.  With your patch, new instances are still 
>>> created for *every* borrow.  The pool and all of its machinery is doing 
>>> nothing other than tracking the number of active instances and making sure 
>>> life cycle events are fired.  If you want the semantics of returning object 
>>> with threads waiting to be that the returning object is passivated, 
>>> activated and handed directly to a waiter without every hitting the idle 
>>> instance pool, that would require rewriting a fair bit of the borrow / 
>>> return code.  It is an interesting idea and would solve the POOL-240 as 
>>> well.
>>> 
>>> One final comment.  If you stick with something like what is in the code 
>>> now, you should make sure to passivate the new instance before putting it 
>>> into the pool.  I just noticed that ensureIdle does not do that, which I 
>>> think is a bug in that method.  So if you want to proceed with this fix, I 
>>> would recommend
>>> 
>>> 1.  Move the ensureIdle activations added in POOL-240 into destroy itself.
>>> 2.  Add passivation to ensureIdle
>>> 3.  Implement corresponding workaround for GKOP
> 
> Sorry, all.  Looking again and thinking a little more, I think the best fix 
> for this is actually to prevent the destroy on return in the first place if 
> there are take waiters.  The maxIdle invariant gets violated with the 
> ensureIdle or direct create() fix anyway and just allowing the returning 
> instance to go into the pool avoids the needless destroy / create sequence.  
> A simple way to do this is just to recode maxIdle before the destroy test in 
> returnObject.
> Instead of
> 
> final int maxIdleSave = getMaxIdle()
> explicitly recode it:
> 
> // If maxIdle is set to 0 and there are take waiters, bump it to 1
> // to preserve liveness.
>  final int maxIdleSave = idleObjects.hasTakeWaiters() ? 
> Math.max(1,getMaxIdle()) : getMaxIdle();
> 
> Phil
> 
>>> 
>>> Phil
>>> 
>>> 
>>>> LieGrue,
>>>> strub
>>>> 
>>>&g

Re: [VOTE] [CANCEL] Release Apache Commons Pool2 2.6.1

[Mark Struberg]

I think we still need to address what happens if null gets returned in create().
This was something I missed.
Not sure if it got addressed in the meantime?

LieGrue,
strub


> Am 26.11.2018 um 14:26 schrieb Rob Tompkins :
> 
> 
> 
>> On Nov 26, 2018, at 8:16 AM, Mark Struberg  wrote:
>> 
>> Hi Gary!
>> 
>> I've added multi-line comments in the middle of code blocks I touched.
>> e.g. 
>> https://github.com/apache/commons-pool/blob/016a1f67263fe1cde1d910dc7002d972811951c5/src/main/java/org/apache/commons/pool2/impl/GenericObjectPool.java#L919
>> 
>> I also tried to write extensive commit comments.
> 
> Sounds good. I’ll try to get to starting the release today. 
> 
> -Rob
> 
>> 
>> LieGrue,
>> strub
>> 
>>> Am 23.11.2018 um 16:18 schrieb Gary Gregory :
>>> 
>>> On Fri, Nov 23, 2018 at 2:57 AM Mark Struberg 
>>> wrote:
>>> 
>>>> should read: This change (putting a new item back to the idle pool) was
>>>> needed to prevent a dead-lock
>>>> 
>>>> *grabbing a fresh coffee*
>>>> 
>>>>> Am 23.11.2018 um 10:49 schrieb Mark Struberg :
>>>>> 
>>>>> This change (putting a new item back to the idle pool was needed to
>>>> prevent a dead-pool
>>>> 
>>> 
>>> Hi Mark,
>>> 
>>> Would you mind adding some comments to the code to help future maintainers?
>>> 
>>> Gary (currently sipping coffee)
>>> 
>>> 
>>>> 
>>>> 
>>>> -
>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>> 
>>>> 
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org


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

Re: [VOTE] [CANCEL] Release Apache Commons Pool2 2.6.1

[Mark Struberg]

Hi Phil!


>  I think that the right answer here is WONT_FIX. That sounds harsh, but it 
> seems to me
> that the obvious solution here is for the user to set maxIdle to at least 1.

I thought about that as well!
Setting maxIdle to 1 will make it less likely but a deadlock will STILL happen.

So I fear we really need to tackle this. Stackoverflow and our own bug tracker 
is full of such reports :(

LieGrue,
strub


> Am 23.11.2018 um 16:51 schrieb Phil Steitz :
> 
> On 11/23/18 2:57 AM, Mark Struberg wrote:
>> should read: This change (putting a new item back to the idle pool) was 
>> needed to prevent a dead-lock
>> 
>> *grabbing a fresh coffee* le
> 
> I am sorry I did not look carefully enough at this issue before reviewing the 
> change.  After reviewing the DBCP ticket (OP likely unrelated, IMO), I think 
> that the right answer here is WONT_FIX. That sounds harsh, but it seems to me 
> that the obvious solution here is for the user to set maxIdle to at least 1.  
> What the fix does is effectively that, without changing the setting.  If 
> waiting threads die or time out while the create is happening, there will be 
> an idle instance in the pool and for certain one is being put there on the 
> way to getting checked back out.  See comments on POOL-327.
> 
> If the consensus is to insert this workaround to enable the pool to retain 
> liveness in the use case, it's probably best to use ensureIdle(1, false) (see 
> POOL-240).  It could be that just moving the call to ensureIdle inside 
> destroy would be OK.  But as stated above, this breaks the maxIdle contract.
> 
> I see that your original report / use case here is from DBCP, Mark.  Was it 
> prepared statements or connections that you were trying to limit to 0 idle?  
> Is there a reason that just using 1 would not work?
> 
> Phil
> 
> 
>> 
>>> Am 23.11.2018 um 10:49 schrieb Mark Struberg :
>>> 
>>> This change (putting a new item back to the idle pool was needed to prevent 
>>> a dead-pool
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>> 
>>> .
>>> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 


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

Re: [VOTE] [CANCEL] Release Apache Commons Pool2 2.6.1

[Mark Struberg]

Hi Gary!

I've added multi-line comments in the middle of code blocks I touched.
e.g. 
https://github.com/apache/commons-pool/blob/016a1f67263fe1cde1d910dc7002d972811951c5/src/main/java/org/apache/commons/pool2/impl/GenericObjectPool.java#L919

I also tried to write extensive commit comments.

LieGrue,
strub

> Am 23.11.2018 um 16:18 schrieb Gary Gregory :
> 
> On Fri, Nov 23, 2018 at 2:57 AM Mark Struberg 
> wrote:
> 
>> should read: This change (putting a new item back to the idle pool) was
>> needed to prevent a dead-lock
>> 
>> *grabbing a fresh coffee*
>> 
>>> Am 23.11.2018 um 10:49 schrieb Mark Struberg :
>>> 
>>> This change (putting a new item back to the idle pool was needed to
>> prevent a dead-pool
>> 
> 
> Hi Mark,
> 
> Would you mind adding some comments to the code to help future maintainers?
> 
> Gary (currently sipping coffee)
> 
> 
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>> 
>> 


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

Re: [VOTE] [CANCEL] Release Apache Commons Pool2 2.6.1

[Mark Struberg]

To clarify why this change was done:
This change (putting a new item back to the idle pool was needed to prevent a 
dead-pool which caused an efective shutdown of all the server by staling the 
pool in various cases.

This solved my problem. I created test to make sure to not introduce new ones. 
But the code is way too much organically grown to be 100% sure. it probably 
need a clean rewrite.
I had another solution which created too many pooled instances. My hope was 
that the create() method will prevent exactly that! If this doesn't work.
Yes, we need to have a null-check on the return param of create and deal with 
that case. But if we still get too many idle objects, then create() is broken 
as well, isn't?

LieGrue,
strub



> Am 19.11.2018 um 23:34 schrieb Gary Gregory :
> 
> 
> diff --git
> a/src/main/java/org/apache/commons/pool2/impl/GenericObjectPool.java
> b/src/main/java/org/apache/commons/pool2/impl/GenericObjectPool.java
> index 0575f7e..6d81dbc 100644
> --- a/src/main/java/org/apache/commons/pool2/impl/GenericObjectPool.java
> +++ b/src/main/java/org/apache/commons/pool2/impl/GenericObjectPool.java
> @@ -920,8 +920,7 @@
> // In case there are already threads waiting on something in
> the pool
> // (e.g. idleObjects.takeFirst(); then we need to provide them
> a fresh instance.
> // Otherwise they will be stuck forever (or until timeout)
> -PooledObject freshPooled = create();
> -idleObjects.put(freshPooled);
> +addObject();
> }
> }
> 
> But causes a failure:
> 
> [INFO] Running org.apache.commons.pool2.impl.TestAbandonedObjectPool
> [ERROR] Tests run: 6, Failures: 1, Errors: 0, Skipped: 0, Time elapsed:
> 12.253 s <<< FAILURE! - in
> org.apache.commons.pool2.impl.TestAbandonedObjectPool
> [ERROR]
> testAbandonedInvalidate(org.apache.commons.pool2.impl.TestAbandonedObjectPool)
> Time elapsed: 3.668 s  <<< FAILURE!
> java.lang.AssertionError: expected:<5> but was:<4>
>at
> org.apache.commons.pool2.impl.TestAbandonedObjectPool.testAbandonedInvalidate(TestAbandonedObjectPool.java:202)
> 
> Maybe this is due to my busy CPU, not sure.
> 
> Gary
> 
> 
>> 
>> Phil
>> 
>> On 11/19/18 2:31 PM, Gary Gregory wrote:
>>> A unit test? Yes please! :-)
>>> 
>>> Gary
>>> 
>>> On Mon, Nov 19, 2018 at 1:23 PM Mark Struberg >> 
>>> wrote:
>>> 
>>>> +1 for the null check.
>>>> 
>>>> Do you want to re-open the ticket and create a patch?
>>>> 
>>>> I've created a unit test which proves my original problem with the
>>>> dead-lock.
>>>> So any improvement should be rather on the safe side from here on.
>>>> 
>>>> 
>>>> Regarding the RC: this is really not needed anymore when working with
>> GIT
>>>> as nothing gets pushed/released to the main repository! See the config
>>>> changes I did to the maven-release-plugin.
>>>> 
>>>> txs and LieGrue,
>>>> strub
>>>> 
>>>> 
>>>> 
>>>>> Am 19.11.2018 um 16:43 schrieb Phil Steitz :
>>>>> 
>>>>> On 11/19/18 8:19 AM, Gary Gregory wrote:
>>>>>> On Mon, Nov 19, 2018 at 6:04 AM Rob Tompkins 
>>>> wrote:
>>>>>>> I’d be happy to roll the release if we get master to where you want
>>>> it.
>>>>>> IMO, we should integrate the recent PR I mentioned and roll RC3. Note
>>>> that this vote subject thread did not contain an RC number. Sticking to
>> the
>>>> usual process would be less troublesome IMO.
>>>>> I have not had a chance to fully review and am not really active in
>>>> [pool] any more, but I did notice that the fix for POOL-356 is missing a
>>>> null check between these two added statements:
>>>>>  PooledObject freshPooled = create();
>>>>> idleObjects.put(freshPooled);
>>>>> 
>>>>> create() can return null and while in general it won't in this
>>>> activation context, given the lack of sync control, it is possible that
>> a
>>>> return hits between the if test and execution resulting in no capacity
>> to
>>>> create.
>>>>> I also notice some system.outs made it into the test code in one of the
>>>> commits related to POOL-340.
>>>>> Phil
>>>>>> Gary
>>>>>> 
>>>>>> 
>>>>>>> Cheers,
>>>>>>> -Rob

Re: [VOTE] [CANCEL] Release Apache Commons Pool2 2.6.1

[Mark Struberg]

should read: This change (putting a new item back to the idle pool) was needed 
to prevent a dead-lock

*grabbing a fresh coffee*

> Am 23.11.2018 um 10:49 schrieb Mark Struberg :
> 
> This change (putting a new item back to the idle pool was needed to prevent a 
> dead-pool


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

Re: [IO] Provenance of copied code in InfiniteCircularInputStream

[Mark Struberg]

+1. This is so trivial that it doesn't pass the threshold of originality.

LieGrue,
strub

> Am 19.11.2018 um 18:15 schrieb Mark Thomas :
> 
> I'd image the comment is referring to the use of "... & 0xFF" but it
> seems to be a fairly pointless comment as that is just the standard way
> to switch from signed byte to 'unsigned' int values.
> 
> I can't see what else it could possibly be referring to.
> 
> I don't see any IP issue here.
> 
> I'd suggest simply removing the comment but with a fairly verbose commit
> message to help anyone looking into this in the future.
> 
> Mark
> 
> 
> On 19/11/2018 16:57, Pascal Schumacher wrote:
>> Hi everybody,
>> 
>> the code is from a pull request which I merged:
>> 
>> https://github.com/apache/commons-io/pull/8
>> 
>> I did not author the code.
>> 
>> The comment seems incorrect because I do not think there is a field
>> "repeatedContent" in java.io.ByteArrayInputStream. The current OpenJDK
>> implementation looks pretty different:
>> 
>> http://hg.openjdk.java.net/jdk/jdk/file/49e0f711bb2b/src/java.base/share/classes/java/io/ByteArrayInputStream.java#l146
>> 
>> 
>> -Pascal
>> 
>> Am 19.11.2018 um 16:59 schrieb Gary Gregory:
>>> Hi All and Pascal S.,
>>> 
>>> Sharon (Eclipse) has pointed out to me that
>>> in org.apache.commons.io.input.InfiniteCircularInputStream.read() [1],
>>> we have:
>>> 
>>> @Override
>>> public int read() {
>>> position = (position + 1) % repeatedContent.length;
>>> return repeatedContent[position] & 0xff; // copied from
>>>  // java.io.ByteArrayInputStream.read()
>>> }
>>> 
>>> Where does the code originate? Oracle JRE? OpenJDK? Where? Such a
>>> comment needs to show better provenance since I am pretty sure we are
>>> NOT allowed to copy code from Oracle.
>>> 
>>> The code was added with the commit
>>> 
>>> https://github.com/apache/commons-io/commit/699d6f0eca65837501d7ab7a92ae2c614f8e6cbf#diff-5cdd5f292c77ae5feee8f3f101ded473
>>> 
>>> 
>>> With this authorship:
>>> 
>>> @piotrturski @PascalSchumacher
>>> 
>>> piotrturski
>>>  authored
>>> and PascalSchumacher
>>>  
>>> committed
>>> on Dec 1, 2015
>>> 
>>> Gary
>>> 
>>> [1]
>>> https://github.com/apache/commons-io/blob/3ad22fe3d689781a76a92908d0bbc119b2c68892/src/main/java/org/apache/commons/io/input/InfiniteCircularInputStream.java#L48-L49
>>> 
>>> 
>> 
>> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 


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

Re: [VOTE] [CANCEL] Release Apache Commons Pool2 2.6.1

[Mark Struberg]

+1 for the null check. 

Do you want to re-open the ticket and create a patch?

I've created a unit test which proves my original problem with the dead-lock. 
So any improvement should be rather on the safe side from here on.


Regarding the RC: this is really not needed anymore when working with GIT as 
nothing gets pushed/released to the main repository! See the config changes I 
did to the maven-release-plugin.

txs and LieGrue,
strub



> Am 19.11.2018 um 16:43 schrieb Phil Steitz :
> 
> On 11/19/18 8:19 AM, Gary Gregory wrote:
>> On Mon, Nov 19, 2018 at 6:04 AM Rob Tompkins  wrote:
>>> I’d be happy to roll the release if we get master to where you want it. 
>> IMO, we should integrate the recent PR I mentioned and roll RC3. Note that 
>> this vote subject thread did not contain an RC number. Sticking to the usual 
>> process would be less troublesome IMO.
> 
> I have not had a chance to fully review and am not really active in [pool] 
> any more, but I did notice that the fix for POOL-356 is missing a null check 
> between these two added statements:
> 
>  PooledObject freshPooled = create();
> idleObjects.put(freshPooled);
> 
> create() can return null and while in general it won't in this activation 
> context, given the lack of sync control, it is possible that a return hits 
> between the if test and execution resulting in no capacity to create.
> 
> I also notice some system.outs made it into the test code in one of the 
> commits related to POOL-340.
> 
> Phil
>> 
>> Gary
>> 
>> 
>>> Cheers,
>>> -Rob
>>> 
>>>> On Nov 19, 2018, at 7:18 AM, Mark Struberg 
>>> wrote:
>>>> Oki, I now see what you mean.
>>>> 
>>>> We actually have 3 source zips now.
>>>> 
>>>> .src.zip
>>>> .source-release.zip
>>>> src.jar
>>>> 
>>>> That's a mess.
>>>> 
>>>> There should only be 2:
>>>> * source-release.zip is the official ASF packages whole build sources.
>>> This includes the pom, build structure etc.
>>>> * src.jar is the sources which are automatically downloaded by the IDEs
>>> for debugging purpose.
>>>> We have both of them because commons-pool2 is a single-module project.
>>>> And yes, we need both of them. What we do not need is the src.zip. I
>>> have no clue yet where this comes from but it shouldn't be here.
>>>> 
>>>> The good news:
>>>> By leveraging native GIT we now can simply a.) drop the maven stating
>>> repo in repository.a.o and b.) drop the release branch and tag from my
>>> github account and re-roll the release without any weird RC hacks.
>>>> Will do that,
>>>> * fix the maven setup
>>>> * happy to also include the new ticket
>>>> * re-roll the release this afternoon.
>>>> 
>>>> LieGrue,
>>>> strub
>>>> 
>>>>> Am 16.11.2018 um 23:10 schrieb Romain Manni-Bucau <
>>> rmannibu...@gmail.com>:
>>>>> Le ven. 16 nov. 2018 22:54, Gary Gregory  a
>>> écrit :
>>>>>> On Fri, Nov 16, 2018 at 2:32 PM Romain Manni-Bucau <
>>> rmannibu...@gmail.com>
>>>>>> wrote:
>>>>>> 
>>>>>>> Le ven. 16 nov. 2018 21:23, Gary Gregory  a
>>>>>> écrit
>>>>>>> :
>>>>>>> 
>>>>>>>> On Wed, Nov 14, 2018 at 8:59 AM Mark Struberg
>>>>>> >>>>>>> wrote:
>>>>>>>> 
>>>>>>>>> Oki, now the full VOTE text!
>>>>>>>>> 
>>>>>>>>> I'd like to call a VOTE on releasing Apache Commons pool2 2.6.1
>>>>>>>>> The release was run with JDK-1.7 to ensure Java7 compatibility.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> The ASF staging repository is at
>>>>>>>>> 
>>> https://repository.apache.org/content/repositories/orgapachecommons-1396/
>>>>>>>>> The source zip is at
>>>>>>>>> 
>>>>>>>>> 
>>> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/
>>>>>>>>> The sha1 of the source-release zip is
>>>>>>>>> 17b01d1e776b7e2b9987b665e1b4e456c02ffa1c
>>>>>>>>> The sha512 is
>>>>>>>>> 
>>>

Re: [VOTE] [CANCEL] Release Apache Commons Pool2 2.6.1

[Mark Struberg]

Oki, I now see what you mean.

We actually have 3 source zips now.

.src.zip
.source-release.zip
src.jar

That's a mess.

There should only be 2:
* source-release.zip is the official ASF packages whole build sources. This 
includes the pom, build structure etc.
* src.jar is the sources which are automatically downloaded by the IDEs for 
debugging purpose.

We have both of them because commons-pool2 is a single-module project.
And yes, we need both of them. What we do not need is the src.zip. I have no 
clue yet where this comes from but it shouldn't be here.


The good news:
By leveraging native GIT we now can simply a.) drop the maven stating repo in 
repository.a.o and b.) drop the release branch and tag from my github account 
and re-roll the release without any weird RC hacks.

Will do that, 
* fix the maven setup
* happy to also include the new ticket
* re-roll the release this afternoon.

LieGrue,
strub

> Am 16.11.2018 um 23:10 schrieb Romain Manni-Bucau :
> 
> Le ven. 16 nov. 2018 22:54, Gary Gregory  a écrit :
> 
>> On Fri, Nov 16, 2018 at 2:32 PM Romain Manni-Bucau 
>> wrote:
>> 
>>> Le ven. 16 nov. 2018 21:23, Gary Gregory  a
>> écrit
>>> :
>>> 
>>>> On Wed, Nov 14, 2018 at 8:59 AM Mark Struberg
>> >>> 
>>>> wrote:
>>>> 
>>>>> Oki, now the full VOTE text!
>>>>> 
>>>>> I'd like to call a VOTE on releasing Apache Commons pool2 2.6.1
>>>>> The release was run with JDK-1.7 to ensure Java7 compatibility.
>>>>> 
>>>>> 
>>>>> The ASF staging repository is at
>>>>> 
>>>> 
>>> 
>> https://repository.apache.org/content/repositories/orgapachecommons-1396/
>>>>> 
>>>>> The source zip is at
>>>>> 
>>>>> 
>>>> 
>>> 
>> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/
>>>>> The sha1 of the source-release zip is
>>>>> 17b01d1e776b7e2b9987b665e1b4e456c02ffa1c
>>>>> The sha512 is
>>>>> 
>>>> 
>>> 
>> 982275c963c09e11dd38a3b6621f2a67bab42b6744a1629ab97b7323208b31730b756a7d5bc6dabee54ba0e9f72c8296904f36919fd421fee8e59786c587c388
>>>>> 
>>>> 
>>>> For me:
>>>> 
>>>> $ sha512sum commons-pool2-2.6.1-src.zip
>>>> 
>>>> 
>>> 
>> 2b95b00a22bf72a7cdf77f2e40796d126b4a0d7b669564b8b04cd0c884252acd3dac356fe55a9fdaadd4767e13eef560995989cb2d39f862f8d3b7e1d06c773e
>>>> *commons-pool2-2.6.1-src.zip
>>>> 
>>>> Which is not what you list above. Please advise.
>>>> 
>>> 
>>> Src vs source-release?
>>> 
>> 
>> That's the problem with inventing a new release process... why do we have
>> BOTH:
>> 
>> 
>> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/commons-pool2-2.6.1-src.zip
>> AND
>> 
>> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/commons-pool2-2.6.1-source-release.zip
>> 
>> And more importantly why are they _different_? Which one will be used in
>> the dist/release area?
>> 
> 
> 
> Looks like pool didnt do its homework and kept the old assembly (src),
> source-release comes from the parent and is likely the one to keep IMHO
> 
> 
>> Gary
>> 
>> 
>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>>> Gary
>>>> 
>>>> 
>>>>> 
>>>>> I added my KEY (struberg at apache.org) to our dist KEYS file
>>>>> https://dist.apache.org/repos/dist/release/commons/KEYS
>>>>> 
>>>>> I've created the release in a GIT manner and pushed the according
>>> changes
>>>>> to my ASF-linked github repo
>>>>> 
>>>>> https://github.com/struberg/commons-pool/tree/release_branch_2.6.1
>>>>> the sha1 of the commit is
>>>>> 
>>>>> 
>>>> 
>>> 
>> https://github.com/struberg/commons-pool/commit/c910171d9d8c8f5f895b7d18381fc03a51b2a019
>>>>> 
>>>>> the tag is
>>>>> https://github.com/struberg/commons-pool/tree/commons-pool2-2.6.1
>>>>> c910171
>>>>> <
>>>> 
>> https://github.com/struberg/commons-pool/tree/commons-pool2-2.6.1c910171
>>>> 
>>>>> 
>>>>> This will ge

Re: Release Managers?

[Mark Struberg]

Let's see how the commons-pool2 release works out. 
If it does then we have significantly reduced the work to run the release.

It's basically down to:

* ensure jira tickets are resolved and tracked in changes.xml
* generate the release_notes updates
* create a release branch with %> git checkout -b release_prj_nnn
* run the mvn release:prepare + mvn release:perform
* review the staging repo at repository.apache.org and close it for the VOTE
* push the release branch + tag to a private repo (so we do not clutter the ASF 
one in case the vote fails later)
* send the VOTE mail pointing to the staging repo

After the vote succeeds:
* propagate/release the Nexus staging repo
* merge the release-branch to master + push the tag to the ASF git repo
* publish the dist/release area from the staging repo or from local.
* create the site, etc

But let's see what I missed before we gonna spread this approach ;)

LieGrue,
strub

PS: for getting GIT setup one needs to tweak the root pom.xlm
https://github.com/apache/commons-pool/blob/master/pom.xml#L188

> Am 13.11.2018 um 20:47 schrieb Bruno P. Kinoshita 
> :
> 
> If anyone would like to take over commons-imaging 1.0-alpha1 release. We had 
> up to RC2 I think, so there should be little left to do.
> I can volunteer around x-mas or January/19 I think.
> Bruno
> 
>  From: Gary Gregory 
> To: Commons Developers List  
> Sent: Wednesday, 14 November 2018 8:34 AM
> Subject: Release Managers?
> 
> Hi All:
> 
> It looks like we have a release manager volunteer for Commons Pool 2.6.1;
> thank you Mark!
> 
> I'd also like to see releases for:
> 
> - Commons Release
> - Commons Parent
> - Commons Text, then Commons Configuration after a teak in Config to use a
> new Text feature.
> - Commons Pool
> - Commons Collection, a request from OpenJPA
> 
> Anything else imminent?
> 
> We also have Commons BeanUtils that will be a major release but I am not
> sure if more API breakage/deprecation is needed.
> 
> Gary
> 
> 


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

Re: [VOTE] Release Apache Commons Pool2 2.6.1

[Mark Struberg]

We've done this since 2011 in a few projects. 
It might seem to not be usual for commons but if you think through then it's 
perfectly ok (and also acked by the board):

A GIT commit is uniquely identified by the sha1 of the parrent commit + the the 
diff of the commit. 
That's the magic why a repo can be cloned and handled independently at all.

When the VOTE did pass we simply do 2 steps:
1.) propagate the staging repo to proper (and check in the source-release.zip 
to our dist/release)
2.) push/merge the changes to master and push it to our cannnonical GIT repo at 
the ASF. + push the tag as well.

The sha1 doesn't change during that step, so it's guaranteed that it's the 
exact same as we voted on.

LieGrue,
strub



> Am 14.11.2018 um 17:15 schrieb Gary Gregory :
> 
> Per http://www.apache.org/legal/release-policy.html#host-rc it should be OK
> to host the RC sources on the Apache Nexus repo instead of the dist tree.
> 
> This is different from how we usually do RCs but is should be OK.
> 
> Not sure about using GitHub though...
> 
> Gary
> 
> On Wed, Nov 14, 2018, 09:00 Mark Struberg  
>> PS: the VOTE is open for 72h from now on.
>> 
>> LieGrue,
>> strub
>> 
>> 
>>> Am 14.11.2018 um 16:58 schrieb Mark Struberg :
>>> 
>>> Oki, now the full VOTE text!
>>> 
>>> I'd like to call a VOTE on releasing Apache Commons pool2 2.6.1
>>> The release was run with JDK-1.7 to ensure Java7 compatibility.
>>> 
>>> 
>>> The ASF staging repository is at
>>> 
>> https://repository.apache.org/content/repositories/orgapachecommons-1396/
>>> 
>>> The source zip is at
>>> 
>> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/
>>> The sha1 of the source-release zip is
>> 17b01d1e776b7e2b9987b665e1b4e456c02ffa1c
>>> The sha512 is
>> 982275c963c09e11dd38a3b6621f2a67bab42b6744a1629ab97b7323208b31730b756a7d5bc6dabee54ba0e9f72c8296904f36919fd421fee8e59786c587c388
>>> 
>>> I added my KEY (struberg at apache.org) to our dist KEYS file
>>> https://dist.apache.org/repos/dist/release/commons/KEYS
>>> 
>>> I've created the release in a GIT manner and pushed the according
>> changes to my ASF-linked github repo
>>> 
>>> https://github.com/struberg/commons-pool/tree/release_branch_2.6.1
>>> the sha1 of the commit is
>>> 
>> https://github.com/struberg/commons-pool/commit/c910171d9d8c8f5f895b7d18381fc03a51b2a019
>>> 
>>> the tag is
>>> https://github.com/struberg/commons-pool/tree/commons-pool2-2.6.1
>>> c910171
>>> 
>>> This will get pushed to the ASF cannonical repo once the VOTE succeeds.
>>> 
>>> Site will be updated once the release has passed.
>>> 
>>> Please VOTE:
>>> 
>>> [+1] go ship it!
>>> [+0] meh, I don't care
>>> [-1] stop there is a ${showstopper} (that means something _important_ is
>> missing!)
>>> 
>>> 
>>> Here is my own +1
>>> checked:
>>> * signature
>>> * hashes
>>> * LICENSE
>>> * NOTICE
>>> * rat
>>> * builds fine with various JDKs
>>> 
>>> 
>>> LieGrue,
>>> strub
>>> 
>>> 
>>> 
>>> 
>>> 
>>>> Am 14.11.2018 um 10:13 schrieb Mark Struberg >> :
>>>> 
>>>> PS: I've created the release in a GIT manner and pushed the according
>> changes to my ASF-linked github repo
>>>> 
>>>> https://github.com/struberg/commons-pool/tree/release_branch_2.6.1
>>>> the sha1 of the commit is
>>>> 
>> https://github.com/struberg/commons-pool/commit/c910171d9d8c8f5f895b7d18381fc03a51b2a019
>>>> 
>>>> the tag is
>>>> https://github.com/struberg/commons-pool/tree/commons-pool2-2.6.1
>>>> c910171
>>>> 
>>>> This will get pushed to the ASF cannonical repo once the VOTE succeeds.
>>>> Yay, this is the way GIT works and before someone not familiar with GIT
>> screams that this is not hosted on ASF: This got discussed on the board
>> level a long time ago (when we did DeltaSpike and CouchDB as the very first
>> GIT repos at the ASF) and is perfectly fine as all this is based on
>> cryptographically strong steps.
>>>> 
>>>> LieGrue,
>>>> strub
>>>> 
>>>> 
>>>>> Am 14.11.2018 um 09:17 schrieb Mark Struberg >> :
>>>>> 
>>>>> Hi folks!
>>>>> 
&g

Re: [VOTE] Release Apache Commons Pool2 2.6.1

[Mark Struberg]

PS: the VOTE is open for 72h from now on.

LieGrue,
strub


> Am 14.11.2018 um 16:58 schrieb Mark Struberg :
> 
> Oki, now the full VOTE text!
> 
> I'd like to call a VOTE on releasing Apache Commons pool2 2.6.1
> The release was run with JDK-1.7 to ensure Java7 compatibility.
> 
> 
> The ASF staging repository is at
> https://repository.apache.org/content/repositories/orgapachecommons-1396/
> 
> The source zip is at 
> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/
> The sha1 of the source-release zip is 17b01d1e776b7e2b9987b665e1b4e456c02ffa1c
> The sha512 is 
> 982275c963c09e11dd38a3b6621f2a67bab42b6744a1629ab97b7323208b31730b756a7d5bc6dabee54ba0e9f72c8296904f36919fd421fee8e59786c587c388
> 
> I added my KEY (struberg at apache.org) to our dist KEYS file
> https://dist.apache.org/repos/dist/release/commons/KEYS
> 
> I've created the release in a GIT manner and pushed the according changes to 
> my ASF-linked github repo
> 
> https://github.com/struberg/commons-pool/tree/release_branch_2.6.1
> the sha1 of the commit is
> https://github.com/struberg/commons-pool/commit/c910171d9d8c8f5f895b7d18381fc03a51b2a019
> 
> the tag is
> https://github.com/struberg/commons-pool/tree/commons-pool2-2.6.1
> c910171
> 
> This will get pushed to the ASF cannonical repo once the VOTE succeeds.
> 
> Site will be updated once the release has passed.
> 
> Please VOTE:
> 
> [+1] go ship it!
> [+0] meh, I don't care
> [-1] stop there is a ${showstopper} (that means something _important_ is 
> missing!)
> 
> 
> Here is my own +1
> checked:
> * signature
> * hashes
> * LICENSE
> * NOTICE
> * rat
> * builds fine with various JDKs
> 
> 
> LieGrue,
> strub 
> 
> 
> 
> 
> 
>> Am 14.11.2018 um 10:13 schrieb Mark Struberg :
>> 
>> PS: I've created the release in a GIT manner and pushed the according 
>> changes to my ASF-linked github repo
>> 
>> https://github.com/struberg/commons-pool/tree/release_branch_2.6.1
>> the sha1 of the commit is
>> https://github.com/struberg/commons-pool/commit/c910171d9d8c8f5f895b7d18381fc03a51b2a019
>> 
>> the tag is
>> https://github.com/struberg/commons-pool/tree/commons-pool2-2.6.1
>> c910171
>> 
>> This will get pushed to the ASF cannonical repo once the VOTE succeeds.
>> Yay, this is the way GIT works and before someone not familiar with GIT 
>> screams that this is not hosted on ASF: This got discussed on the board 
>> level a long time ago (when we did DeltaSpike and CouchDB as the very first 
>> GIT repos at the ASF) and is perfectly fine as all this is based on 
>> cryptographically strong steps.
>> 
>> LieGrue,
>> strub
>> 
>> 
>>> Am 14.11.2018 um 09:17 schrieb Mark Struberg :
>>> 
>>> Hi folks!
>>> 
>>> I'm currently preparing the release for commons-pool2-2.6.1
>>> 
>>> So far I did 
>>> 
>>> * fix the missing parts in changes.xml
>>> * generate + copy the RELEASE_NOTES
>>> * run the maven release (after fixing the setup...)
>>> 
>>> The ASF staging repository is at
>>> https://repository.apache.org/content/repositories/orgapachecommons-1396/
>>> 
>>> The source zip is at 
>>> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/
>>> The sha1 of the source-release zip is 
>>> 17b01d1e776b7e2b9987b665e1b4e456c02ffa1c
>>> The sha512 is 
>>> 982275c963c09e11dd38a3b6621f2a67bab42b6744a1629ab97b7323208b31730b756a7d5bc6dabee54ba0e9f72c8296904f36919fd421fee8e59786c587c388
>>> 
>>> I added my KEY (struberg at apache.org) to our dist KEYS file
>>> https://dist.apache.org/repos/dist/release/commons/KEYS
>>> 
>>> I will now continue with the follow up steps and then call an official VOTE.
>>> 
>>> Please let me know if something went wrong so far!
>>> 
>>> LieGrue,
>>> strub
>>> 
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>> 
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>> 
> 


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

Re: [VOTE] Release Apache Commons Pool2 2.6.1

[Mark Struberg]

Oki, now the full VOTE text!

I'd like to call a VOTE on releasing Apache Commons pool2 2.6.1
The release was run with JDK-1.7 to ensure Java7 compatibility.


The ASF staging repository is at
https://repository.apache.org/content/repositories/orgapachecommons-1396/

The source zip is at 
https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/
The sha1 of the source-release zip is 17b01d1e776b7e2b9987b665e1b4e456c02ffa1c
The sha512 is 
982275c963c09e11dd38a3b6621f2a67bab42b6744a1629ab97b7323208b31730b756a7d5bc6dabee54ba0e9f72c8296904f36919fd421fee8e59786c587c388

I added my KEY (struberg at apache.org) to our dist KEYS file
https://dist.apache.org/repos/dist/release/commons/KEYS

I've created the release in a GIT manner and pushed the according changes to my 
ASF-linked github repo

https://github.com/struberg/commons-pool/tree/release_branch_2.6.1
the sha1 of the commit is
https://github.com/struberg/commons-pool/commit/c910171d9d8c8f5f895b7d18381fc03a51b2a019

the tag is
https://github.com/struberg/commons-pool/tree/commons-pool2-2.6.1
c910171

This will get pushed to the ASF cannonical repo once the VOTE succeeds.

Site will be updated once the release has passed.

Please VOTE:

[+1] go ship it!
[+0] meh, I don't care
[-1] stop there is a ${showstopper} (that means something _important_ is 
missing!)


Here is my own +1
checked:
* signature
* hashes
* LICENSE
* NOTICE
* rat
* builds fine with various JDKs


LieGrue,
strub 





> Am 14.11.2018 um 10:13 schrieb Mark Struberg :
> 
> PS: I've created the release in a GIT manner and pushed the according changes 
> to my ASF-linked github repo
> 
> https://github.com/struberg/commons-pool/tree/release_branch_2.6.1
> the sha1 of the commit is
> https://github.com/struberg/commons-pool/commit/c910171d9d8c8f5f895b7d18381fc03a51b2a019
> 
> the tag is
> https://github.com/struberg/commons-pool/tree/commons-pool2-2.6.1
> c910171
> 
> This will get pushed to the ASF cannonical repo once the VOTE succeeds.
> Yay, this is the way GIT works and before someone not familiar with GIT 
> screams that this is not hosted on ASF: This got discussed on the board level 
> a long time ago (when we did DeltaSpike and CouchDB as the very first GIT 
> repos at the ASF) and is perfectly fine as all this is based on 
> cryptographically strong steps.
> 
> LieGrue,
> strub
> 
> 
>> Am 14.11.2018 um 09:17 schrieb Mark Struberg :
>> 
>> Hi folks!
>> 
>> I'm currently preparing the release for commons-pool2-2.6.1
>> 
>> So far I did 
>> 
>> * fix the missing parts in changes.xml
>> * generate + copy the RELEASE_NOTES
>> * run the maven release (after fixing the setup...)
>> 
>> The ASF staging repository is at
>> https://repository.apache.org/content/repositories/orgapachecommons-1396/
>> 
>> The source zip is at 
>> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/
>> The sha1 of the source-release zip is 
>> 17b01d1e776b7e2b9987b665e1b4e456c02ffa1c
>> The sha512 is 
>> 982275c963c09e11dd38a3b6621f2a67bab42b6744a1629ab97b7323208b31730b756a7d5bc6dabee54ba0e9f72c8296904f36919fd421fee8e59786c587c388
>> 
>> I added my KEY (struberg at apache.org) to our dist KEYS file
>> https://dist.apache.org/repos/dist/release/commons/KEYS
>> 
>> I will now continue with the follow up steps and then call an official VOTE.
>> 
>> Please let me know if something went wrong so far!
>> 
>> LieGrue,
>> strub
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 


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

Re: [all] Amazon Corretto

[Mark Struberg]

One more option.
Which is good for the Java ecosystem. 

LieGrue,
strub

> Am 14.11.2018 um 15:14 schrieb Rob Tompkins :
> 
> Curious to see what people’s thoughts are to this:
> 
> https://aws.amazon.com/corretto/
> 
> -Rob
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 


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

Re: [VOTE] Release Apache Commons Pool2 2.6.1

[Mark Struberg]

PS: I've created the release in a GIT manner and pushed the according changes 
to my ASF-linked github repo

https://github.com/struberg/commons-pool/tree/release_branch_2.6.1
the sha1 of the commit is
https://github.com/struberg/commons-pool/commit/c910171d9d8c8f5f895b7d18381fc03a51b2a019

the tag is
https://github.com/struberg/commons-pool/tree/commons-pool2-2.6.1
c910171

This will get pushed to the ASF cannonical repo once the VOTE succeeds.
Yay, this is the way GIT works and before someone not familiar with GIT screams 
that this is not hosted on ASF: This got discussed on the board level a long 
time ago (when we did DeltaSpike and CouchDB as the very first GIT repos at the 
ASF) and is perfectly fine as all this is based on cryptographically strong 
steps.

LieGrue,
strub


> Am 14.11.2018 um 09:17 schrieb Mark Struberg :
> 
> Hi folks!
> 
> I'm currently preparing the release for commons-pool2-2.6.1
> 
> So far I did 
> 
> * fix the missing parts in changes.xml
> * generate + copy the RELEASE_NOTES
> * run the maven release (after fixing the setup...)
> 
> The ASF staging repository is at
> https://repository.apache.org/content/repositories/orgapachecommons-1396/
> 
> The source zip is at 
> https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/
> The sha1 of the source-release zip is 17b01d1e776b7e2b9987b665e1b4e456c02ffa1c
> The sha512 is 
> 982275c963c09e11dd38a3b6621f2a67bab42b6744a1629ab97b7323208b31730b756a7d5bc6dabee54ba0e9f72c8296904f36919fd421fee8e59786c587c388
> 
> I added my KEY (struberg at apache.org) to our dist KEYS file
> https://dist.apache.org/repos/dist/release/commons/KEYS
> 
> I will now continue with the follow up steps and then call an official VOTE.
> 
> Please let me know if something went wrong so far!
> 
> LieGrue,
> strub
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 


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

[VOTE] Release Apache Commons Pool2 2.6.1

[Mark Struberg]

Hi folks!

I'm currently preparing the release for commons-pool2-2.6.1

So far I did 

* fix the missing parts in changes.xml
* generate + copy the RELEASE_NOTES
* run the maven release (after fixing the setup...)

The ASF staging repository is at
https://repository.apache.org/content/repositories/orgapachecommons-1396/

The source zip is at 
https://repository.apache.org/content/repositories/orgapachecommons-1396/org/apache/commons/commons-pool2/2.6.1/
The sha1 of the source-release zip is 17b01d1e776b7e2b9987b665e1b4e456c02ffa1c
The sha512 is 
982275c963c09e11dd38a3b6621f2a67bab42b6744a1629ab97b7323208b31730b756a7d5bc6dabee54ba0e9f72c8296904f36919fd421fee8e59786c587c388

I added my KEY (struberg at apache.org) to our dist KEYS file
https://dist.apache.org/repos/dist/release/commons/KEYS

I will now continue with the follow up steps and then call an official VOTE.

Please let me know if something went wrong so far!

LieGrue,
strub


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

Re: [VOTE][CANCEL] Release Apache Commons Pool 2.6.1 based on RC1

[Mark Struberg]

yes, they are. I create a new test to showcase the problem and only then fix it.
All other tests still pass.

LieGrue,
strub


> Am 12.11.2018 um 16:05 schrieb Gary Gregory :
> 
> Hi Mark,
> 
> Too many bits flying around on my end here. Can you check that your changes
> are covered by unit tests? That should do it I hope.
> 
> Gary
> 
> On Mon, Nov 12, 2018 at 12:56 AM Mark Struberg 
> wrote:
> 
>> sorry should have read "did anyone TEST my pool fixes".
>> 
>> LieGrue,
>> strub
>> 
>> 
>>> Am 10.11.2018 um 23:24 schrieb Gary Gregory :
>>> 
>>> On Sat, Nov 10, 2018 at 1:24 PM Mark Struberg >> 
>>> wrote:
>>> 
>>>> Did anyone fix my pool fixes?
>>> 
>>> 
>>> Hi Mark,
>>> 
>>> Can you be more specific or just check git master?
>>> 
>>> 
>>>> The latest deployed pool and dbcp2 snapshots do contain them.
>>>> 
>>> 
>>> So we are good then, right?
>>> 
>>> 
>>>> Would love to start a release but I think I need some guidance.
>>>> Any docs for how it runs in commons land?
>>>> 
>>> 
>>> I think Rob updated the Wiki:
>> https://commons.apache.org/releases/index.html
>>> 
>>> Gary
>>> 
>>> 
>>>> txs and LieGrue,strub
>>>> 
>>>>   On Friday, 2 November 2018, 17:01:44 CET, Gary Gregory <
>>>> garydgreg...@gmail.com> wrote:
>>>> 
>>>> I am cancelling this VOTE, long overdue, sorry. There are additional bug
>>>> fixes that have come in as well...
>>>> 
>>>> Gary
>>>> 
>>>> On Thu, Aug 23, 2018 at 7:39 AM Gary Gregory 
>>>> wrote:
>>>> 
>>>>> 
>>>>> 
>>>>> On Wed, Aug 22, 2018 at 1:14 PM Benedikt Ritter 
>>>>> wrote:
>>>>> 
>>>>>> Hi Gary,
>>>>>> Am Mi., 22. Aug. 2018 um 16:04 Uhr schrieb Gary Gregory <
>>>>>> garydgreg...@gmail.com>:
>>>>>> 
>>>>>>> WRT signing tags, ATM, I cannot git's -s option to work with GPG on
>>>>>>> Windows. Any clues?
>>>>>>> 
>>>>>> 
>>>>>> Sorry, I'm on macOS. For that to work I needed to have the gpg-agent
>>>>>> running. But I don't know whether this is a unix thing.
>>>>>> 
>>>>>> The tag signing alone would not cause me to vote -1. I can live with
>> an
>>>>>> unsigned tag. What really needs to be fixed are the differences
>> between
>>>>>> src
>>>>>> distribution and release tag in my opinion. I'll have time on Saturday
>>>> to
>>>>>> have a look into that if you don't get to it until then.
>>>>>> 
>>>>> 
>>>>> I welcome the help :-) Quite busy at work.
>>>>> 
>>>>> Gary
>>>>> 
>>>>>> 
>>>>>> Regards,
>>>>>> Benedikt
>>>>>> 
>>>>>> 
>>>>>>> 
>>>>>>> Gary
>>>>>>> 
>>>>>>> On Tue, Aug 21, 2018 at 1:06 AM Benedikt Ritter 
>>>>>>> wrote:
>>>>>>> 
>>>>>>>> Hello Gary,
>>>>>>>> 
>>>>>>>> -1, I there are several issues that we need to fix this before we
>>>> can
>>>>>>>> release 2.6.1.
>>>>>>>> 
>>>>>>>> I think the RELEASE NOTES need more work:
>>>>>>>> 
>>>>>>>> "The Apache Commons Pool team is pleased to announce the release of
>>>>>>> Apache
>>>>>>>> Commons Pool 2.6.1-SNAPSHOT."
>>>>>>>> "No client code changes are required to migrate from versions
>>>> 2.0-2.3
>>>>>> to
>>>>>>>> version 2.4.3." - what about migration to 2.6.1?
>>>>>>>> "Version 2 requires JDK level 1.6 or above" - Website states that
>>>>>> Java 7
>>>>>>> is
>>>>>>>> required.
>>>>>>>> 
>>>>>>>> The release tag is not signed:
>>>>>>>> ~/w/a/r/p/commons-pool git:(master) > git tag -v
>>&g

Re: [VOTE][CANCEL] Release Apache Commons Pool 2.6.1 based on RC1

[Mark Struberg]

sorry should have read "did anyone TEST my pool fixes".

LieGrue,
strub


> Am 10.11.2018 um 23:24 schrieb Gary Gregory :
> 
> On Sat, Nov 10, 2018 at 1:24 PM Mark Struberg 
> wrote:
> 
>> Did anyone fix my pool fixes?
> 
> 
> Hi Mark,
> 
> Can you be more specific or just check git master?
> 
> 
>> The latest deployed pool and dbcp2 snapshots do contain them.
>> 
> 
> So we are good then, right?
> 
> 
>> Would love to start a release but I think I need some guidance.
>> Any docs for how it runs in commons land?
>> 
> 
> I think Rob updated the Wiki: https://commons.apache.org/releases/index.html
> 
> Gary
> 
> 
>> txs and LieGrue,strub
>> 
>>On Friday, 2 November 2018, 17:01:44 CET, Gary Gregory <
>> garydgreg...@gmail.com> wrote:
>> 
>> I am cancelling this VOTE, long overdue, sorry. There are additional bug
>> fixes that have come in as well...
>> 
>> Gary
>> 
>> On Thu, Aug 23, 2018 at 7:39 AM Gary Gregory 
>> wrote:
>> 
>>> 
>>> 
>>> On Wed, Aug 22, 2018 at 1:14 PM Benedikt Ritter 
>>> wrote:
>>> 
>>>> Hi Gary,
>>>> Am Mi., 22. Aug. 2018 um 16:04 Uhr schrieb Gary Gregory <
>>>> garydgreg...@gmail.com>:
>>>> 
>>>>> WRT signing tags, ATM, I cannot git's -s option to work with GPG on
>>>>> Windows. Any clues?
>>>>> 
>>>> 
>>>> Sorry, I'm on macOS. For that to work I needed to have the gpg-agent
>>>> running. But I don't know whether this is a unix thing.
>>>> 
>>>> The tag signing alone would not cause me to vote -1. I can live with an
>>>> unsigned tag. What really needs to be fixed are the differences between
>>>> src
>>>> distribution and release tag in my opinion. I'll have time on Saturday
>> to
>>>> have a look into that if you don't get to it until then.
>>>> 
>>> 
>>> I welcome the help :-) Quite busy at work.
>>> 
>>> Gary
>>> 
>>>> 
>>>> Regards,
>>>> Benedikt
>>>> 
>>>> 
>>>>> 
>>>>> Gary
>>>>> 
>>>>> On Tue, Aug 21, 2018 at 1:06 AM Benedikt Ritter 
>>>>> wrote:
>>>>> 
>>>>>> Hello Gary,
>>>>>> 
>>>>>> -1, I there are several issues that we need to fix this before we
>> can
>>>>>> release 2.6.1.
>>>>>> 
>>>>>> I think the RELEASE NOTES need more work:
>>>>>> 
>>>>>> "The Apache Commons Pool team is pleased to announce the release of
>>>>> Apache
>>>>>> Commons Pool 2.6.1-SNAPSHOT."
>>>>>> "No client code changes are required to migrate from versions
>> 2.0-2.3
>>>> to
>>>>>> version 2.4.3." - what about migration to 2.6.1?
>>>>>> "Version 2 requires JDK level 1.6 or above" - Website states that
>>>> Java 7
>>>>> is
>>>>>> required.
>>>>>> 
>>>>>> The release tag is not signed:
>>>>>> ~/w/a/r/p/commons-pool git:(master) > git tag -v
>>>> commons-pool-2.6.1-RC1
>>>>>> object 87c5dc14a967a70dd6e640395d4e842b021cdb8f
>>>>>> type commit
>>>>>> tag commons-pool-2.6.1-RC1
>>>>>> tagger Gary Gregory  1534517006 -0600
>>>>>> 
>>>>>> Tag Apache Commons Pool release 2.6.1 RC1
>>>>>> error: no signature found
>>>>>> 
>>>>>> There are various differences between to release tag in git and the
>>>>>> contents of the src archive:
>>>>>> ~/w/a/r/pool-2.6.1 > diff -rq commons-pool commons-pool2-2.6.1-src
>>>>>> Only in commons-pool: .git
>>>>>> Only in commons-pool: .gitignore
>>>>>> Only in commons-pool: .travis.yml
>>>>>> Only in commons-pool: CONTRIBUTING.md
>>>>>> Files commons-pool/NOTICE.txt and commons-pool2-2.6.1-src/NOTICE.txt
>>>>> differ
>>>>>> Only in commons-pool: README.md
>>>>>> Files commons-pool/RELEASE-NOTES.txt and
>>>>>> commons-pool2-2.6.1-src/RELEASE-NOTES.txt differ
>>>>>> Files commons-pool/pom.xml and commons-pool2-2.6.1-src/pom.xml
>> differ
>>&

Re: [VOTE][CANCEL] Release Apache Commons Pool 2.6.1 based on RC1

[Mark Struberg]

 Did anyone fix my pool fixes?The latest deployed pool and dbcp2 snapshots do 
contain them.
Would love to start a release but I think I need some guidance. 
Any docs for how it runs in commons land?
txs and LieGrue,strub

On Friday, 2 November 2018, 17:01:44 CET, Gary Gregory 
 wrote:  
 
 I am cancelling this VOTE, long overdue, sorry. There are additional bug
fixes that have come in as well...

Gary

On Thu, Aug 23, 2018 at 7:39 AM Gary Gregory  wrote:

>
>
> On Wed, Aug 22, 2018 at 1:14 PM Benedikt Ritter 
> wrote:
>
>> Hi Gary,
>> Am Mi., 22. Aug. 2018 um 16:04 Uhr schrieb Gary Gregory <
>> garydgreg...@gmail.com>:
>>
>> > WRT signing tags, ATM, I cannot git's -s option to work with GPG on
>> > Windows. Any clues?
>> >
>>
>> Sorry, I'm on macOS. For that to work I needed to have the gpg-agent
>> running. But I don't know whether this is a unix thing.
>>
>> The tag signing alone would not cause me to vote -1. I can live with an
>> unsigned tag. What really needs to be fixed are the differences between
>> src
>> distribution and release tag in my opinion. I'll have time on Saturday to
>> have a look into that if you don't get to it until then.
>>
>
> I welcome the help :-) Quite busy at work.
>
> Gary
>
>>
>> Regards,
>> Benedikt
>>
>>
>> >
>> > Gary
>> >
>> > On Tue, Aug 21, 2018 at 1:06 AM Benedikt Ritter 
>> > wrote:
>> >
>> > > Hello Gary,
>> > >
>> > > -1, I there are several issues that we need to fix this before we can
>> > > release 2.6.1.
>> > >
>> > > I think the RELEASE NOTES need more work:
>> > >
>> > > "The Apache Commons Pool team is pleased to announce the release of
>> > Apache
>> > > Commons Pool 2.6.1-SNAPSHOT."
>> > > "No client code changes are required to migrate from versions 2.0-2.3
>> to
>> > > version 2.4.3." - what about migration to 2.6.1?
>> > > "Version 2 requires JDK level 1.6 or above" - Website states that
>> Java 7
>> > is
>> > > required.
>> > >
>> > > The release tag is not signed:
>> > > ~/w/a/r/p/commons-pool git:(master) > git tag -v
>> commons-pool-2.6.1-RC1
>> > > object 87c5dc14a967a70dd6e640395d4e842b021cdb8f
>> > > type commit
>> > > tag commons-pool-2.6.1-RC1
>> > > tagger Gary Gregory  1534517006 -0600
>> > >
>> > > Tag Apache Commons Pool release 2.6.1 RC1
>> > > error: no signature found
>> > >
>> > > There are various differences between to release tag in git and the
>> > > contents of the src archive:
>> > > ~/w/a/r/pool-2.6.1 > diff -rq commons-pool commons-pool2-2.6.1-src
>> > > Only in commons-pool: .git
>> > > Only in commons-pool: .gitignore
>> > > Only in commons-pool: .travis.yml
>> > > Only in commons-pool: CONTRIBUTING.md
>> > > Files commons-pool/NOTICE.txt and commons-pool2-2.6.1-src/NOTICE.txt
>> > differ
>> > > Only in commons-pool: README.md
>> > > Files commons-pool/RELEASE-NOTES.txt and
>> > > commons-pool2-2.6.1-src/RELEASE-NOTES.txt differ
>> > > Files commons-pool/pom.xml and commons-pool2-2.6.1-src/pom.xml differ
>> > > Only in commons-pool: pool-RC.sh
>> > > Only in commons-pool: pool-pre-RC.sh
>> > > Only in commons-pool: pool-release.sh
>> > > Only in commons-pool/src: assembly
>> > > Files commons-pool/src/changes/changes.xml and
>> > > commons-pool2-2.6.1-src/src/changes/changes.xml differ
>> > > Files commons-pool/src/site/resources/download_pool.cgi and
>> > > commons-pool2-2.6.1-src/src/site/resources/download_pool.cgi differ
>> > > Files commons-pool/src/site/site.xml and
>> > > commons-pool2-2.6.1-src/src/site/site.xml differ
>> > > Files commons-pool/src/site/xdoc/index.xml and
>> > > commons-pool2-2.6.1-src/src/site/xdoc/index.xml differ
>> > > Files commons-pool/src/site/xdoc/issue-tracking.xml and
>> > > commons-pool2-2.6.1-src/src/site/xdoc/issue-tracking.xml differ
>> > >
>> > > Some of them are okay (e.g. git files) but others are not (like
>> > > changes.xml)
>> > >
>> > > The build works on my machine using:
>> > > ~/w/a/r/p/commons-pool2-2.6.1-src > mvn -version
>> > > Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe;
>> > > 2018-06-17T20:33:14+02:00)
>> > > Maven home: /usr/local/Cellar/maven/3.5.4/libexec
>> > > Java version: 1.8.0_161, vendor: Oracle Corporation, runtime:
>> > > /Library/Java/JavaVirtualMachines/jdk1.8.0_161.jdk/Contents/Home/jre
>> > > Default locale: de_DE, platform encoding: UTF-8
>> > > OS name: "mac os x", version: "10.13.6", arch: "x86_64", family: "mac"
>> > >
>> > > Regards,
>> > > Benedikt
>> > >
>> > > Am Fr., 17. Aug. 2018 um 18:08 Uhr schrieb Gary Gregory <
>> > > ggreg...@apache.org
>> > > >:
>> > >
>> > > > We have fixed one bug and updated optional dependencies since Apache
>> > > > Commons Pool 2.6.0 was released, so I would like to release Apache
>> > > Commons
>> > > > Pool 2.6.1.
>> > > >
>> > > > Apache Commons Pool 2.6.1 RC1 is available for review here:
>> > > >    https://dist.apache.org/repos/dist/dev/commons/pool/2.6.1-RC1
>> (svn
>> > > > revision 28810)
>> > > >
>> > > > The Git tag commons-pool-2.6.1-RC1 commit for this RC is
>> > > > 

Re: [pool] how to move to Java8?

[Mark Struberg]

Yes, was not sure whether the changes.xml is generated or hand crafted.
Gonna add the missing bits.


LieGrue,
strub

> Am 29.10.2018 um 16:17 schrieb Gary Gregory :
> 
> My view is to skip POOL-355 and release the current code still, on Java
> 7, as 2.6.1, or 2.7.0 if a new feature has been added, which is not clear
> since it seems changes.xml has not been updated for the commits over the
> last week or two.
> 
> Gary
> 
> On Mon, Oct 29, 2018 at 6:49 AM Mark Struberg 
> wrote:
> 
>> I've went through the list and pretty much the only ticket which was left
>> to really benefit from it would be the getMaxNumActive() (POOL-355).
>> But as noted there: after a bit of thinking through it I'm even tempted to
>> close it as won't fix. Having just a bare maxNumActive doesn't give you
>> much info in real production.
>> What you need is really a time graph with the currently active
>> connections. You usually don't care about just a short spike e.g. because
>> the underlying db gets restarted. What you care about is whether the
>> connections are fine NOW and at which timeframe they have been in a bad
>> shape.
>> 
>> If you (and others) could also take a look on this ticket them we could go
>> on and close it. Which whould then remove the need for Java8.
>> 
>> That means I'm perfectly fine with keeping it java7 for now. Plus we also
>> know what to take care of if we really need to bump to j8.
>> 
>> LieGrue,
>> strub
>> 
>> 
>>> Am 29.10.2018 um 09:35 schrieb Mark Thomas :
>>> 
>>> On 28/10/18 11:09, Mark Struberg wrote:
>>>> Hi folks!
>>>> I've worked through the open POOL tickets and found a few tickets which
>> would like to enhance a few of our interfaces.
>>>> E.g. in POOL-355 we have a request to add a new method
>> getMaxNumActive() to the ObjectPool interface.
>>>> Now this would of course be a backward compatibility breaking change.
>> If we would have java8 as minimum then we could easily just add a default
>> method which returns -1. But since our min Java version is 1.7 we are
>> doomed...
>>>> I would love to get the deadlock fixes out with the current 1.7
>> requirement first. Because that's important to get to the people (including
>> my own customers).
>>>> But what after that?Would this justify a commons-pool-3.0?Do we also
>> like to cleanup other stuff? Or should we just raise our min Java
>> requirement to 1.8 and call it 2.7?
>>>> I'm totally fine either way and would love to get any feedback.
>>> 
>>> Tomcat 8 (with a spec required minimum Java version of Java 7) is
>>> currently using the latest version of pool. This version of Tomcat is
>>> unlikely to be EOL until well into the 2020s. It would be easier if pool
>>> stayed on Java 7 (since we maintain a package renamed copy of the code)
>>> but I appreciate that that is not practical for pool for that timescale.
>>> 
>>> It isn't a huge amount of work to handle things like default methods.
>>> The Tomcat community would certainly appreciate it if any Java 8
>>> specific changes in Pool kept in mind that Tomcat will need to back-port
>>> them to Java 7.
>>> 
>>> Mark
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>> 
>> 


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

Re: [pool] how to move to Java8?

[Mark Struberg]

I've went through the list and pretty much the only ticket which was left to 
really benefit from it would be the getMaxNumActive() (POOL-355).
But as noted there: after a bit of thinking through it I'm even tempted to 
close it as won't fix. Having just a bare maxNumActive doesn't give you much 
info in real production.
What you need is really a time graph with the currently active connections. You 
usually don't care about just a short spike e.g. because the underlying db gets 
restarted. What you care about is whether the connections are fine NOW and at 
which timeframe they have been in a bad shape.

If you (and others) could also take a look on this ticket them we could go on 
and close it. Which whould then remove the need for Java8.

That means I'm perfectly fine with keeping it java7 for now. Plus we also know 
what to take care of if we really need to bump to j8.

LieGrue,
strub


> Am 29.10.2018 um 09:35 schrieb Mark Thomas :
> 
> On 28/10/18 11:09, Mark Struberg wrote:
>> Hi folks!
>> I've worked through the open POOL tickets and found a few tickets which 
>> would like to enhance a few of our interfaces.
>> E.g. in POOL-355 we have a request to add a new method getMaxNumActive() to 
>> the ObjectPool interface.
>> Now this would of course be a backward compatibility breaking change. If we 
>> would have java8 as minimum then we could easily just add a default method 
>> which returns -1. But since our min Java version is 1.7 we are doomed...
>> I would love to get the deadlock fixes out with the current 1.7 requirement 
>> first. Because that's important to get to the people (including my own 
>> customers).
>> But what after that?Would this justify a commons-pool-3.0?Do we also like to 
>> cleanup other stuff? Or should we just raise our min Java requirement to 1.8 
>> and call it 2.7?
>> I'm totally fine either way and would love to get any feedback.
> 
> Tomcat 8 (with a spec required minimum Java version of Java 7) is
> currently using the latest version of pool. This version of Tomcat is
> unlikely to be EOL until well into the 2020s. It would be easier if pool
> stayed on Java 7 (since we maintain a package renamed copy of the code)
> but I appreciate that that is not practical for pool for that timescale.
> 
> It isn't a huge amount of work to handle things like default methods.
> The Tomcat community would certainly appreciate it if any Java 8
> specific changes in Pool kept in mind that Tomcat will need to back-port
> them to Java 7.
> 
> Mark
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org


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

Re: [VOTE][CANCEL] Release Apache Commons Pool 2.6.1 based on RC1

[Mark Struberg]

Txs gary!

When will there be a new reelase run?

If it's worth I could also do the release manager IF the project is properly 
set up.
Means if it's a straight forward maven release then I gonna run it the same as 
my other dozen ASF projects.

LieGrue,
strub


> Am 28.10.2018 um 15:29 schrieb Gary Gregory :
> 
> I am canceling this VOTE. It is stale and I've not taken the time to look
> into the tagging issue. Furthermore, there are additional fixes that have
> just come in.
> 
> Gary
> 
> On Thu, Aug 23, 2018 at 7:39 AM Gary Gregory  wrote:
> 
>> 
>> 
>> On Wed, Aug 22, 2018 at 1:14 PM Benedikt Ritter 
>> wrote:
>> 
>>> Hi Gary,
>>> Am Mi., 22. Aug. 2018 um 16:04 Uhr schrieb Gary Gregory <
>>> garydgreg...@gmail.com>:
>>> 
 WRT signing tags, ATM, I cannot git's -s option to work with GPG on
 Windows. Any clues?
 
>>> 
>>> Sorry, I'm on macOS. For that to work I needed to have the gpg-agent
>>> running. But I don't know whether this is a unix thing.
>>> 
>>> The tag signing alone would not cause me to vote -1. I can live with an
>>> unsigned tag. What really needs to be fixed are the differences between
>>> src
>>> distribution and release tag in my opinion. I'll have time on Saturday to
>>> have a look into that if you don't get to it until then.
>>> 
>> 
>> I welcome the help :-) Quite busy at work.
>> 
>> Gary
>> 
>>> 
>>> Regards,
>>> Benedikt
>>> 
>>> 
 
 Gary
 
 On Tue, Aug 21, 2018 at 1:06 AM Benedikt Ritter 
 wrote:
 
> Hello Gary,
> 
> -1, I there are several issues that we need to fix this before we can
> release 2.6.1.
> 
> I think the RELEASE NOTES need more work:
> 
> "The Apache Commons Pool team is pleased to announce the release of
 Apache
> Commons Pool 2.6.1-SNAPSHOT."
> "No client code changes are required to migrate from versions 2.0-2.3
>>> to
> version 2.4.3." - what about migration to 2.6.1?
> "Version 2 requires JDK level 1.6 or above" - Website states that
>>> Java 7
 is
> required.
> 
> The release tag is not signed:
> ~/w/a/r/p/commons-pool git:(master) > git tag -v
>>> commons-pool-2.6.1-RC1
> object 87c5dc14a967a70dd6e640395d4e842b021cdb8f
> type commit
> tag commons-pool-2.6.1-RC1
> tagger Gary Gregory  1534517006 -0600
> 
> Tag Apache Commons Pool release 2.6.1 RC1
> error: no signature found
> 
> There are various differences between to release tag in git and the
> contents of the src archive:
> ~/w/a/r/pool-2.6.1 > diff -rq commons-pool commons-pool2-2.6.1-src
> Only in commons-pool: .git
> Only in commons-pool: .gitignore
> Only in commons-pool: .travis.yml
> Only in commons-pool: CONTRIBUTING.md
> Files commons-pool/NOTICE.txt and commons-pool2-2.6.1-src/NOTICE.txt
 differ
> Only in commons-pool: README.md
> Files commons-pool/RELEASE-NOTES.txt and
> commons-pool2-2.6.1-src/RELEASE-NOTES.txt differ
> Files commons-pool/pom.xml and commons-pool2-2.6.1-src/pom.xml differ
> Only in commons-pool: pool-RC.sh
> Only in commons-pool: pool-pre-RC.sh
> Only in commons-pool: pool-release.sh
> Only in commons-pool/src: assembly
> Files commons-pool/src/changes/changes.xml and
> commons-pool2-2.6.1-src/src/changes/changes.xml differ
> Files commons-pool/src/site/resources/download_pool.cgi and
> commons-pool2-2.6.1-src/src/site/resources/download_pool.cgi differ
> Files commons-pool/src/site/site.xml and
> commons-pool2-2.6.1-src/src/site/site.xml differ
> Files commons-pool/src/site/xdoc/index.xml and
> commons-pool2-2.6.1-src/src/site/xdoc/index.xml differ
> Files commons-pool/src/site/xdoc/issue-tracking.xml and
> commons-pool2-2.6.1-src/src/site/xdoc/issue-tracking.xml differ
> 
> Some of them are okay (e.g. git files) but others are not (like
> changes.xml)
> 
> The build works on my machine using:
> ~/w/a/r/p/commons-pool2-2.6.1-src > mvn -version
> Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe;
> 2018-06-17T20:33:14+02:00)
> Maven home: /usr/local/Cellar/maven/3.5.4/libexec
> Java version: 1.8.0_161, vendor: Oracle Corporation, runtime:
> /Library/Java/JavaVirtualMachines/jdk1.8.0_161.jdk/Contents/Home/jre
> Default locale: de_DE, platform encoding: UTF-8
> OS name: "mac os x", version: "10.13.6", arch: "x86_64", family: "mac"
> 
> Regards,
> Benedikt
> 
> Am Fr., 17. Aug. 2018 um 18:08 Uhr schrieb Gary Gregory <
> ggreg...@apache.org
>> :
> 
>> We have fixed one bug and updated optional dependencies since Apache
>> Commons Pool 2.6.0 was released, so I would like to release Apache
> Commons
>> Pool 2.6.1.
>> 
>> Apache Commons Pool 2.6.1 RC1 is available for review here:
>>https://dist.apache.org/repos/dist/dev/commons/pool/2.6.1-RC1
>>> (svn
>> revision 28810)
>> 
>> The Git tag 

[pool] how to move to Java8?

[Mark Struberg]

Hi folks!
I've worked through the open POOL tickets and found a few tickets which would 
like to enhance a few of our interfaces.
E.g. in POOL-355 we have a request to add a new method getMaxNumActive() to the 
ObjectPool interface.
Now this would of course be a backward compatibility breaking change. If we 
would have java8 as minimum then we could easily just add a default method 
which returns -1. But since our min Java version is 1.7 we are doomed...
I would love to get the deadlock fixes out with the current 1.7 requirement 
first. Because that's important to get to the people (including my own 
customers).
But what after that?Would this justify a commons-pool-3.0?Do we also like to 
cleanup other stuff? Or should we just raise our min Java requirement to 1.8 
and call it 2.7?
I'm totally fine either way and would love to get any feedback.

LieGrue,strub

[pool] ignored but working PoolTest

[Mark Struberg]

Hi Gary!
I've seen that PoolTest is ignored since you committed it back in 2016. But 
it's actually all green.Is there still something missing? Or can we simply 
enable it?
txs and LieGrue,strub

Re: [VOTE] Release Apache Commons Configuration 2.4 based on RC2

[Mark Struberg]

Looks like a glitch. 
The class looks exactly the same like in 2.3.

LieGrue,
strub

> Am 25.10.2018 um 00:11 schrieb Gary Gregory :
> 
> I do not understand why Clirr is showing one error here:
> https://dist.apache.org/repos/dist/dev/commons/configuration/2.4-RC2/site/clirr-report.html
> 
> Could this be a false positive?
> 
> Gary
> 
> On Tue, Oct 23, 2018 at 8:10 PM Rob Tompkins  wrote:
> 
>> We have fixed quite a few bugs and added some significant enhancements
>> since Apache Commons Configuration 2.3 was released, so I would like to
>> release Apache Commons Configuration 2.4.
>> 
>> Apache Commons Configuration 2.4 RC2 is available for review here:
>>https://dist.apache.org/repos/dist/dev/commons/configuration/2.4-RC2
>> (svn revision 30260)
>> 
>> The Subversion tag for this RC is here:
>> 
>> http://svn.apache.org/repos/asf/commons/proper/configuration/tags/CONFIGURATION_2_4_RC2/
>> (svn revision 1844715)
>> 
>> Maven artifacts are here:
>> 
>> https://repository.apache.org/content/repositories/orgapachecommons-1391/org/apache/commons/commons-configuration2/2.4/
>> 
>> These are the Maven artifacts and their hashes in Nexus:
>> 
>> #Nexus SHA-1s
>> 
>> commons-configuration2-2.4-sources.jar=2bcdd60dac93e16b53f613f37979b585cb5c23ec
>> commons-configuration2-2.4.pom=24b3e7ef8afc470ead058236dd71a73a0f029d9d
>> 
>> commons-configuration2-2.4-test-sources.jar=1f1fc7fad84049f55a6b9f28e9cacde46971bad6
>> 
>> commons-configuration2-2.4-tests.jar=a6c0ef84d06fb110681ee4ffc46f8d2d0436d203
>> 
>> commons-configuration2-2.4-javadoc.jar=e73305477e5d62ad0e140b58aa7e87dd0dbd1266
>> commons-configuration2-2.4.jar=208279841cb092e0f51f097c1f1649341e6333f3
>> 
>> #Release SHA-256s
>> #Tue Oct 23 21:49:00 EDT 2018
>> 
>> commons-configuration2-2.4-bin-tar.gz=25a59714dbeb379263d5b05d88a22ce0a6521cbd4b29e0d43630e8375cbb2776
>> 
>> commons-configuration2-2.4-bin-zip=cb9b1979ec07dbfb7ffc8b1a4e897210942ab85e8c91fcaba0a2de88fad274cd
>> 
>> commons-configuration2-2.4-src-tar.gz=1c24b4a507a7688e26af3b508eb85cf954a92ac3dc2ffa841bb114c345fb2d97
>> 
>> commons-configuration2-2.4-src-zip=d6ac9d51fb29426746916265c072e370a2b1a3720c8891bba8621720c3f479c8
>> 
>> I have tested this with 'mvn clean install site' using:
>> Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe;
>> 2018-06-17T14:33:14-04:00)
>> Maven home: /usr/local/Cellar/maven/3.5.4/libexec
>> Java version: 1.8.0_181, vendor: Oracle Corporation, runtime:
>> /Library/Java/JavaVirtualMachines/jdk1.8.0_181.jdk/Contents/Home/jre
>> Default locale: en_US, platform encoding: UTF-8
>> OS name: "mac os x", version: "10.14", arch: "x86_64", family: "mac"
>> 
>> Details of changes since 2.3 are in the release notes:
>> 
>> https://dist.apache.org/repos/dist/dev/commons/configuration/2.4-RC2/RELEASE-NOTES.txt
>> 
>> https://dist.apache.org/repos/dist/dev/commons/configuration/2.4-RC2/site/changes-report.html
>> 
>> Site:
>> 
>> https://dist.apache.org/repos/dist/dev/commons/configuration/2.4-RC2/site
>>(note some *relative* links are broken and the 2.4 directories are not
>> yet created - these will be OK once the site is deployed.)
>> 
>> CLIRR Report (compared to 2.3):
>> 
>> https://dist.apache.org/repos/dist/dev/commons/configuration/2.4-RC2/site/clirr-report.html
>> 
>> JApiCmp Report (compared to 2.3):
>> 
>> https://dist.apache.org/repos/dist/dev/commons/configuration/2.4-RC2/site/japicmp.html
>> 
>> RAT Report:
>> 
>> https://dist.apache.org/repos/dist/dev/commons/configuration/2.4-RC2/site/rat-report.html
>> 
>> KEYS:
>>  https://www.apache.org/dist/commons/KEYS
>> 
>> Please review the release candidate and vote.
>> This vote will close no sooner that 72 hours from now.
>> 
>>  [ ] +1 Release these artifacts
>>  [ ] +0 OK, but...
>>  [ ] -0 OK, but really should fix...
>>  [ ] -1 I oppose this release because...
>> 
>> Thank you,
>> 
>> Rob Tompkins,
>> Release Manager (using key B6E73D84EA4FCC47166087253FAAD2CD5ECBB314)
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>> 
>> 


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

POOL-356 deadlock patch

[Mark Struberg]

hi folks!
Would be cool if someone firm in this project might review my patch for 
POOL-356https://github.com/apache/commons-pool/pull/11
I gonna commit it tomorrow morning if there was no negative feedback.
txs and LieGrue,strub

usage of System.currentTimeMillis();

[Mark Struberg]

Hi folks!
While fixing a deadlock in commons-pool I also stumbled across 
System.currentTimeMillis();quite a few times.It's no biggie but I would still 
love to get your feedback and experience.
If I remember correctly then one should use Sytem.nanoTime() in those cases.a.) 
afair currentTimeMIllis() might jump back in time (on NTP syncs, etc).b.) on 
Linux currentTimeMillis might be way more expensive than System.nanoTime(); 
Mainly depending on whether the underlying HPET is used (slow) or another timer 
source.

What is your experience? Is this still correct?Or is this gone with new boards 
and more recent JVMs?
LieGrue,strub

Re: [VOTE] Release Apache Commons Weaver 2.0 based on RC1

[Mark Struberg]

checked the source zip from 
https://dist.apache.org/repos/dist/dev/commons/weaver/2.0-RC1/source/

sha512 fine
sig fine
builds fine
RAT passes.

+1


LieGrue,
strub

> Am 04.09.2018 um 17:58 schrieb Matt Benson :
> 
> I would like to release the [weaver] component.
> 
> Apache Commons Weaver 2.0 RC1 is available for review at:
>  *https://dist.apache.org/repos/dist/dev/commons/weaver/2.0-RC1/
> * (r29084).
> 
> Maven artifacts are at:
>  https://repository.apache.org/content/repositories/orgapachecommons-1377 .
> 
> Tested with Oracle JDKs 8 and 10.
> 
> The Git tag is:
> 
> https://gitbox.apache.org/repos/asf?p=commons-weaver.git;a=tag;h=0eed2d07008fd2bfad32b6f8a03da0299cc61d65
> .
> 
> Site (note some links may be broken; this will be fixed when the site
> is deployed):
> 
> https://dist.apache.org/repos/dist/dev/commons/weaver/2.0-RC1/site/index.html
> 
> RAT Report:
> 
> https://dist.apache.org/repos/dist/dev/commons/weaver/2.0-RC1/site/rat-report.html
> 
> Quality Reports (PMD/Checkstyle/Findbugs/japicmp):
> 
> https://dist.apache.org/repos/dist/dev/commons/weaver/2.0-RC1/site/commons-weaver-parent/commons-weaver-processor/project-reports.html
> 
> https://dist.apache.org/repos/dist/dev/commons/weaver/2.0-RC1/site/commons-weaver-parent/commons-weaver-modules-parent/commons-weaver-privilizer-parent/commons-weaver-privilizer-api/project-reports.html
> 
> https://dist.apache.org/repos/dist/dev/commons/weaver/2.0-RC1/site/commons-weaver-parent/commons-weaver-modules-parent/commons-weaver-privilizer-parent/commons-weaver-privilizer/project-reports.html
> 
> https://dist.apache.org/repos/dist/dev/commons/weaver/2.0-RC1/site/commons-weaver-parent/commons-weaver-modules-parent/commons-weaver-normalizer/project-reports.html
> 
> https://dist.apache.org/repos/dist/dev/commons/weaver/2.0-RC1/site/commons-weaver-parent/commons-weaver-maven-plugin/project-reports.html
> 
> https://dist.apache.org/repos/dist/dev/commons/weaver/2.0-RC1/site/commons-weaver-parent/commons-weaver-antlib/project-reports.html
> 
> Keys: https://dist.apache.org/repos/dist/release/commons/KEYS
> 
> Please review the release candidate and vote.
>  This vote will close no sooner than 72 hours from now, i.e. after
> 1600UTC 7-September 2018
> 
>  [ ] +1 Release these artifacts
>  [ ] +0 OK, but...
>  [ ] -0 OK, but really should fix...
>  [ ] -1 I oppose this release because...
> 
>  Thanks!


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

Re: [WEAVER] Incomplete git migration?

[Mark Struberg]

The git repo is on ASF gitbox
https://gitbox.apache.org/repos/asf/commons-weaver.git

It's also listed on the gitbox overview page:
https://gitbox.apache.org/repos/asf

And here is the ASF mirror on GitHub
https://github.com/apache/commons-weaver


LieGrue,
strub


> Am 05.09.2018 um 08:46 schrieb Benedikt Ritter :
> 
> Hi,
> 
> I'm trying to check the latest commons weaver RC but I can't find the
> source repository. Matt posted a link to a Git tag, so I suspect the weaver
> uses git. If that is the case, it looks to me like the git migration is
> incomplete. The old source tree in SVN is still in it's place and has not
> been moved to the moved_to_git folder. Further more the website still has
> SVN URLs which should be updated to the new git URLs. Commons Weaver
> doesn't show up on http://git.apache.org. I tried
> https://git-wip-us.apache.org/repos/asf/commons-weaver.git but there is no
> repository there. Where can I find the codebase?
> 
> Regards,
> Benedikt


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

Re: [weaver] preparing a 1.4 release

[Mark Struberg]

+1 for a commons-weaver release.

txs and LieGrue,
strub


> Am 03.08.2018 um 02:04 schrieb Gary Gregory :
> 
> Good luck! :-)
> 
> On Thu, Aug 2, 2018, 17:59 Matt Benson  wrote:
> 
>> Hello,
>> If it wasn't obvious, I'm gearing up to create a 1.4 RC in the near future.
>> I will serve as the release manager; please respond with any concerns.
>> 
>> Thanks,
>> Matt
>> 


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

Re: [ALL] SHA256/512 hashes

[Mark Struberg]

> This is unlikely to happen as long as it does not cover multi-module builds

The maven-release-plugin covers multi-module releases since many years.

In the projects I'm working on there is no 'release manager'.
_Everybody_ can do releases without having to know anything special.
This is where the maven-release-plugin really shines. 
Just use mvn release:prepare + mvn release:perform and be done.

Of course it's fine if projects use ant, etc.
But ideally there should be a single way to kick of a release (fully automated, 
same target name across projects, etc)

LieGrue,
strub


> Am 26.08.2018 um 10:43 schrieb Thomas Vandahl :
> 
> On 25.08.18 16:14, Gilles wrote:
 Probably for those who don't want to use the release plugin :-)
>>> 
>>> I was mainly following up on the thread about updating CP to AP 21 [1]
>>> 
>>> But yes, it could be used as an alternative hashing method.
>> 
>> I thought that the release plugin was intended for all
>> components to converge on the same release "recipe"...
> 
> This is unlikely to happen as long as it does not cover multi-module builds.
> 
> Bye, Thomas.
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 


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

rolling a commons-weaver release?

[Mark Struberg]

Hi folks!

I'd like to run a commons-weaver release.
We need it for Apache BVal.

The new version adds Java9+10 support, etc

Any objections?


LieGrue,
strub


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

Re: [VOTE] Release Apache Commons JCS 2.0-beta-2 based on RC1

[Mark Struberg]

+1

LieGrue,
strub


> Am 24.10.2016 um 14:36 schrieb Johannes Weberhofer 
> :
> 
> 
> 
> Am 21.10.2016 um 19:42 schrieb Thomas Vandahl:
>> I would like to beta-release the [jcs] component.
>> 
>> Apache Commons JCS 2.0-beta-2 RC1 is available for review at:
>>  https://dist.apache.org/repos/dist/dev/commons/jcs/ (r16621).
>> 
>> Maven artifacts are at:
>>  https://repository.apache.org/content/repositories/orgapachecommons-1211 .
>> 
>> The Subversion tag is:
>> 
>> https://svn.apache.org/repos/asf/commons/proper/jcs/tags/commons-jcs-2.0-beta-2
>> (r1766068).
>> 
>> The release notes are at:
>> 
>> https://svn.apache.org/repos/asf/commons/proper/jcs/tags/commons-jcs-2.0-beta-2/RELEASE-NOTES.txt
>> (r1766068).
>> 
>> Please review the release candidate and vote.
>> 
>>  [ ] +1 Release these artifacts
>>  [ ] +0 OK, but...
>>  [ ] -0 OK, but really should fix...
>>  [ ] -1 I oppose this release because...
>> 
>> Please be lenient with me as this is my first Commons release attempt.
>> 
>> Bye, Thomas
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>> 
> 
> Dear Thomas,
> 
> thanks for releasing that version! Compared to former builds the tests are 
> much faster (When I remember right, it took me more than 10 minutes to create 
> a package before). This is a non-binding +1!
> 
> I have replaced a beta1 version by this version in a testing software it runs 
> without any issues so far.
> 
> Best regard,
> Johannes
> 
> 
> Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 
> 2015-11-10T17:41:47+01:00)
> Maven home: /opt/apache-maven
> Java version: 1.8.0_101, vendor: Oracle Corporation
> Java home: /usr/lib64/jvm/java-1.8.0-openjdk-1.8.0/jre
> Default locale: de_DE, platform encoding: UTF-8
> OS name: "linux", version: "4.8.2-3.g5e4310e-default", arch: "amd64", family: 
> "unix"
> 
> [INFO] 
> 
> [INFO] Reactor Summary:
> [INFO]
> [INFO] Apache Commons JCS . SUCCESS [ 25.442 
> s]
> [INFO] Apache Commons JCS :: Core . SUCCESS [03:49 
> min]
> [INFO] Apache Commons JCS :: JCache ... SUCCESS [  2.810 
> s]
> [INFO] Apache Commons JCS :: JCache TCK ... SUCCESS [  2.437 
> s]
> [INFO] Apache Commons JCS :: JCache Extras  SUCCESS [  7.353 
> s]
> [INFO] Apache Commons JCS :: JCache OpenJPA ... SUCCESS [  3.318 
> s]
> [INFO] Apache Commons JCS :: Distribution . SUCCESS [  0.218 
> s]
> [INFO] 
> 
> [INFO] BUILD SUCCESS
> [INFO] 
> 
> [INFO] Total time: 04:31 min
> [INFO] Finished at: 2016-10-24T12:24:41+02:00
> [INFO] Final Memory: 58M/489M
> [INFO] 
> 
> 
> 
> 
> -- 
> Johannes Weberhofer
> Weberhofer GmbH, Austria, Vienna
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 


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

Re: [collection][security] InvokerTransformer missused in java object serialisation exploits

[Mark Struberg]

SecurityManager is an ancient part and heavily slows down the JVM. That’s the 
reason why almost nobody is using it.

LieGrue,
strub


> Am 08.11.2015 um 20:20 schrieb James Carman :
> 
> I think this entire thing can be prevented with a security manager and a
> proper policy in place. Nobody does that, though
> 
> On Sun, Nov 8, 2015 at 2:10 PM Thomas Neidhart 
> wrote:
> 
>> On 11/08/2015 07:51 PM, James Carman wrote:
>>> Couldn't they use the same attack vector to set a system property also? I
>>> do believe that would be possible
>> 
>> for this you need a way to execute code via a de-serialized class.
>> Right now, the simplest way to do so is via the InvokerTransformer.
>> 
>> There are surely other ways to do so, but if the only available way is
>> blocked (i.e. InvokerTransformer can not be deserialized), a remote
>> attacker cannot set a system property via this attack vector.
>> 
>> btw. setting a system property can also be restricted by a SecurityManager.
>> 
>> I am -1 on a programmatic interface, and for the 4.X branch I propose to
>> remove the serialization support completely.
>> 
>> Thomas
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org


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

Re: [VOTE][JCS] release [jcs] 2.0-beta-1 (take 3)

[Mark Struberg]

Sebb, this is nowhere stated in the bylaws. There is just no ground for totally 
blasting a release!

It's superfluous and not 100% perfect but it is NOT wrong. The sources 
_currenty_ contain this file, so we have it.

For how long is this now in the codebase? 2 years? even longer?
Be glad that Romain finally cleans this up.
It's not perfect but it's also not a show stopper. And instead of ranting you 
could have easily fixed it in SVN in the meantime.

LieGrue,
strub






 On Monday, 26 January 2015, 17:59, sebb seb...@gmail.com wrote:
  On 26 January 2015 at 16:47, Romain Manni-Bucau rmannibu...@gmail.com 
 wrote:
  2015-01-26 17:41 GMT+01:00 sebb seb...@gmail.com:
  On 26 January 2015 at 12:20, Romain Manni-Bucau 
 rmannibu...@gmail.com wrote:
  Ok so you only speak about dist src bundle?
 
  No, it also affects the binary bundle, and it affects the SVN tag
  (which is also a distribution, though not a release)
 
 
  Not the bundle since aspectj files are not here and keeping xerox
  reference is not an issue just something we should avoid if possible
  nor the tag since the tag is fine (the tag uses module license and
  global one - bundle - doesnt make any sense). So it only affects
  sources one.
 
 The NOTICE file is wrong, whether or not the xerox file is included.
 NOTICE files must not contain spurious text.
 
 This affects the source and binary bundles and the jars (binary and source)
 
  Not sure it does need to cancel the vote, this is not a major issue
  IMO and can be fixed for next one
 
  Given how infrequently releases are made, I don't think that is a 
 good idea.
 
 
 
 
  Romain Manni-Bucau
  @rmannibucau
  http://www.tomitribe.com
  http://rmannibucau.wordpress.com
  https://github.com/rmannibucau
 
 
  2015-01-26 12:39 GMT+01:00 sebb seb...@gmail.com:
  On 26 January 2015 at 11:30, Romain Manni-Bucau 
 rmannibu...@gmail.com wrote:
  @sebb: not sure I get it right, it references LICENSE.txt 
 correctly for me
 
  Not sure what you mean by it above.
 
  As I already wrote:
  The NOTICE file should not reference LICENSE.txt
  Nor should it reference LICENSE.xerox, because the Xerox 
 license does
  not require attribution.
 
  However LICENSE.txt must include - or point to as separate 
 file(s) -
  any 3rd party licenses for bundled code.
  It does not reference xerox currently, so there is a problem 
 which
  arises because of the source file.
 
  The user must be able to determine the licensing requirements 
 from
  LICENSE and NOTICE without having to look around for other 
 license
  files.
  And the NOTICE file must not contain anything that is not 
 required.
 
 
  Romain Manni-Bucau
  @rmannibucau
  http://www.tomitribe.com
  http://rmannibucau.wordpress.com
  https://github.com/rmannibucau
 
 
  2015-01-26 12:27 GMT+01:00 sebb seb...@gmail.com:
  On 26 January 2015 at 11:19, Romain Manni-Bucau 
 rmannibu...@gmail.com wrote:
  if that's the case +1 but anyway it doesnt hurt
 
  But it does have some consequences, because of the 
 license issues.
 
  @Thomas: before dropping it can you confirm it a 
 last time please?
 
 
  Romain Manni-Bucau
  @rmannibucau
  http://www.tomitribe.com
  http://rmannibucau.wordpress.com
  https://github.com/rmannibucau
 
 
  2015-01-26 12:18 GMT+01:00 sebb 
 seb...@gmail.com:
  Why not just drop it entirely?
 
  If that is the only Xerox-licensed file, it is 
 not essential to the
  operation of JCS, so why keep it?
 
  On 25 January 2015 at 21:44, Romain Manni-Bucau 
 rmannibu...@gmail.com wrote:
  Hi Mark,
 
  this is not packaged AFAIK, just here as a 
 sample I guess.
 
 
  Romain Manni-Bucau
  @rmannibucau
  http://www.tomitribe.com
  http://rmannibucau.wordpress.com
  https://github.com/rmannibucau
 
 
  2015-01-25 22:35 GMT+01:00 Mark Struberg 
 strub...@yahoo.de:
  is that all?
 
 https://svn.apache.org/repos/asf/commons/proper/jcs/trunk/commons-jcs-core/src/aspect/org/apache/commons/Trace.aj
 
  Wouldn't it be actually quite easy 
 to replace this?
 
 
 
  LieGrue,
  strub
 
 
 
 
 
  On Sunday, 25 January 2015, 19:30, 
 Thomas Vandahl t...@apache.org wrote:
   On 25.01.15 17:00, Romain 
 Manni-Bucau wrote:
   It does AFAIK - was not here 
 and just propagated existing legal text - and
   that is why it is referenced 
 in core and not all artifacts.
Le 25 janv. 2015 16:55, 
 sebb seb...@gmail.com a écrit
  :
 
  The XEROX license relates to the 
 file
 
 /commons-jcs-core/src/aspect/org/apache/commons/Trace.aj
 
  If the file continues to be part of 
 the distribution, the license file
  must be present, at least that is 
 my understanding of the Apache
  requirements.
 
  This was discussed at length when 
 JCS 1.3 was released.
 
  Bye, Thomas.
 
 
 
 
 
 -
  To unsubscribe, e-mail: 
 dev-unsubscr...@commons.apache.org
  For additional commands, e-mail: 
 dev-h...@commons.apache.org

Re: [VOTE][JCS] release [jcs] 2.0-beta-1 (take 3)

[Mark Struberg]

is that all?
https://svn.apache.org/repos/asf/commons/proper/jcs/trunk/commons-jcs-core/src/aspect/org/apache/commons/Trace.aj

Wouldn't it be actually quite easy to replace this?



LieGrue,
strub





 On Sunday, 25 January 2015, 19:30, Thomas Vandahl t...@apache.org wrote:
  On 25.01.15 17:00, Romain Manni-Bucau wrote:
  It does AFAIK - was not here and just propagated existing legal text - and
  that is why it is referenced in core and not all artifacts.
   Le 25 janv. 2015 16:55, sebb seb...@gmail.com a écrit 
 :
 
 The XEROX license relates to the file
 /commons-jcs-core/src/aspect/org/apache/commons/Trace.aj
 
 If the file continues to be part of the distribution, the license file
 must be present, at least that is my understanding of the Apache
 requirements.
 
 This was discussed at length when JCS 1.3 was released.
 
 Bye, Thomas.
 
 
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org


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

Re: Announce: Commons Inject

[Mark Struberg]

Hi Jochen!


The code is now indeed self-contained. I did not really look at the code but 
like to start with just a few small observations:

1.) the repo contains the whole eclipse project files. I'd rather remove those 
from the repos and add them (+ idea files) to svn:ignore.

2.) javax-inject.api. I'd probably replace this via our own impl:
http://repo1.maven.org/maven2/org/apache/geronimo/specs/geronimo-atinject_1.0_spec/1.0/

3.) the atinject (JSR-330) TCK. I compiled the project and it only said it 
passes 2 tests. I double checked with OpenWebBeans and over there we run (and 
pass of course) 50 tests. Maybe there is something wrong with the integration?

4.) the Scopes.
You currently have a Enum for this. I guess it would be pretty easy to switch 
this to using scope annotations which are meta-annotated with @Scope instead? 
And also implement the @Singleton scope based on that approach instead of 
rolling your own?


Just a few ideas. 


LieGrue,
strub







 On Wednesday, 17 December 2014, 13:56, Jochen Wiedmann 
 jochen.wiedm...@gmail.com wrote:
  Well spotted. I had added Guice as a Maven dependency so as to
 validate certain things while implementing. It's now removed. This
 should eliminate your concerns. Also, please note that the remaining
 dependencies are all provided, with the exception of
 javax.inject-1.jar and javax.inject-tck-1.jar, which are required for
 obvious reasons. (After all, this is the implemented standard.)
 
 
 
 On Wed, Dec 17, 2014 at 11:52 AM, Benedikt Ritter brit...@apache.org 
 wrote:
  2014-11-19 8:44 GMT+01:00 Mark Struberg strub...@yahoo.de:
 
  Jochen, I might have done something wrong so please help me.
 
  I've checked out your svn link and built it.
 
  Then I did a
 
  $ mvn clean -DincludeScope=runtime dependency:copy-dependencies
  -rw-r--r--+ 1 struberg staff4467 19. Nov 08:41 aopalliance-1.0.jar
  -rw-r--r--+ 1 struberg staff 2228009 19. Nov 08:41 guava-16.0.1.jar
  -rw-r--r--+ 1 struberg staff  642741 19. Nov 08:41 guice-4.0-beta5.jar
  -rw-r--r--+ 1 struberg staff2497 19. Nov 08:41 javax.inject-1.jar
 
 
  $ du -hs target/dependencies
 
  show me 2.8 MB
 
 
  Plus your own jar which is 76k.
  Is there something wrong? What are you using guice and guava for?
  Also there is an own ASF package for atinject [1].
 
 
  Jochen, can you please comment?
 
  Benedikt
 
 
 
  LieGrue,
  strub
 
 
 
  [1]
 
 http://repo1.maven.org/maven2/org/apache/geronimo/specs/geronimo-atinject_1.0_spec/1.0/
 
 
 
 
  On Wednesday, 19 November 2014, 8:34, Mark Struberg 
 strub...@yahoo.de
  wrote:
   Sorry, did not mean to step on somebody's toes.
  
  No worries you didn't. It's most probably our fault as our 
 (OpenWebBeans)
  documentation sucks and we did not properly document all this stuff ;)
  
  If one of you guys is at ApacheCon in Budapest right now, then 
 I'd love
  to give you a quick rush through our code an see if there is something 
 you
  could use and also if we could improve something in OWB.
  
  LieGrue,
  strub
  
  
  
  
  - Original Message -
   From: Oliver Heger oliver.he...@oliver-heger.de
   To: Commons Developers List dev@commons.apache.org
   Cc:
   Sent: Sunday, 9 November 2014, 11:45
   Subject: Re: Announce: Commons Inject
  
  
  
   On 08.11.2014 21:51, Romain Manni-Bucau wrote:
Le 8 nov. 2014 19:51, Oliver Heger
   oliver.he...@oliver-heger.de a écrit
:
  
Hi Jochen,
  
do you intend to position this framework for specific 
 use cases? In
which way is it different or special from other 
 implementations?
  
Just as one example: In the company I am working for, 
 we are using
  CDI
in a pretty large JSE application. Due to the huge 
 class path the
  setup
of the CDI container takes a long time and consumes a 
 lot of memory
(tested with both Weld SE and OpenWebBeans). So a 
 fast and
  lightweight
implementation for this special purpose would be 
 interesting.
  
  
Surely a bad example since you can achieve it with owb, 
 just
  configure the
scanner service
  
   Sorry, did not mean to step on somebody's toes.
  
   Oliver
  
  
Oliver
  
Am 04.11.2014 um 15:55 schrieb Jochen Wiedmann:
Hi,
  
As some of you (hopefulyl not all) may have 
 noticed, have added a
project called Commons Inject to the Sandbox [1] 
 today. Commons
   Inject
is a JSR 330 compliant dependency injection 
 framework. It is
   something
I had in the works for quite some time, but now 
 it has reached a
decent state with my preliminary milestones 
 reached:
  
- Passes the JSR 330 TCK.
- Integrated lifecycle handling via 
 @PostConstruct and @PreDestroy.
Works with all scopes,
   including lazy singletons. (I never got this 
 to work with Guice,
which has been my major
   driver for doing this.)
- Integrated logger injection framework for 
 Log4J, SLF4J, and
   Commons
Logging. Others can
   easily be added.
  
I intend to use

commons-parent maven pom highly broken?

[Mark Struberg]

Hi!

I've never seen any other ASF project where it is such a torture to release.
This is partly because the quality level is really high, but a big part of it 
is that we don't have a mature parent pom. 


I have no clue why we don't just use the common apache parent pom. I've NEVER 
experienced such issues like missing NOTICE and LICENSE with it. It's really 
much more solid than our own one.

LieGrue,
strub

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

Re: commons-parent maven pom highly broken?

[Mark Struberg]

Just file an JIRA if something doesn't work and you are done. 


 Releasing is tedious because Maven does not really support non-Maven
 release directories (i.e. www.apache.org/dist/commons)
This is totally non-ASF style. Just use the standard stuff like every other ASF 
project and you are again done.


 Until very recently the ASF parent pom was broken, and with no sign of
 any fixes.To me'not fixing anything' would mean that all the apache-parent 
 releases would be useless?

Or you just did not check it?


 There are stil issues with LICENSE and NOTICE, because the
 automatically created ones are not always correct.
The rule is straight forward. If you provide your own one then it will be used. 
If not, then a standard one will be packaged.


 The Commons Pom includes a lot of common setup that would otherwise
 have to be added to each component's parent pom.
And that would be? Most of the stuff is taken over from the old ant builds and 
nowadays do not reflect reality anymore.


 There are various other additional optional features in the Commons
 pom which are useful for testing.
what more than testng OR junit (depending on the project) + maybe mock tools do 
you need?


 I think the CP pom works fine for single module projects.
 I'm not sure about multimodule projects, but is the ASF pom any better?
Well, most of todays projects are multi-module ones. And this works perfectly 
fine with the ASF parent pom.



LieGrue,
strub




 On Saturday, 13 December 2014, 18:41, sebb seb...@gmail.com wrote:
  On 13 December 2014 at 12:26, Mark Struberg strub...@yahoo.de wrote:
  Hi!
 
  I've never seen any other ASF project where it is such a torture to 
 release.
  This is partly because the quality level is really high, but a big part of 
 it is that we don't have a mature parent pom.
 
 Sorry, but I don't think that is at all relevant.
 Releasing is tedious because Maven does not really support non-Maven
 release directories (i.e. www.apache.org/dist/commons) so work-rounds
 are needed.
 This is true whatever the parent pom is used.
 
 It's partly also that Maven does some things well, but when
 adjustments are needed, it can be all but impossible to work out how
 to coax it to do what's needed.
 
 
  I have no clue why we don't just use the common apache parent pom. 
 I've NEVER experienced such issues like missing NOTICE and LICENSE with it. 
 It's really much more solid than our own one.
 
 Until very recently the ASF parent pom was broken, and with no sign of
 any fixes.
 For example, it did not allow override of the compiler plugin version,
 and there were a few other issues with it.
 
 There are stil issues with LICENSE and NOTICE, because the
 automatically created ones are not always correct.
 I'm not sure it creates the appropriate source and javadoc jars either.
 
 And it does not create decent manifests.
 
 The Commons Pom includes a lot of common setup that would otherwise
 have to be added to each component's parent pom.
 That is not an efficient way of proceeding.
 
 There are various other additional optional features in the Commons
 pom which are useful for testing.
 
 I think the CP pom works fine for single module projects.
 I'm not sure about multimodule projects, but is the ASF pom any better?
 
 Rather than raise unsubstantiated criticisms of the CP pom, file bugs
 for any problems and/or try fixing them.
 
 
  LieGrue,
  strub
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
  For additional commands, e-mail: dev-h...@commons.apache.org
 
 

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

Re: Announce: Commons Inject

[Mark Struberg]

Hi Olivier!

There are ways to just exclude known jars from getting scanned by OpenWebBeans. 
And if the current solution isn't sufficient then just pop up on our list and 
we gonna implement it. Maybe I've overlooked you on the list or did you not yet 
reach out to us?


LieGrue,
strub





- Original Message -
 From: Oliver Heger oliver.he...@oliver-heger.de
 To: Commons Developers List dev@commons.apache.org
 Cc: 
 Sent: Saturday, 8 November 2014, 20:51
 Subject: Re: Announce: Commons Inject
 
 Hi Jochen,
 
 do you intend to position this framework for specific use cases? In
 which way is it different or special from other implementations?
 
 Just as one example: In the company I am working for, we are using CDI
 in a pretty large JSE application. Due to the huge class path the setup
 of the CDI container takes a long time and consumes a lot of memory
 (tested with both Weld SE and OpenWebBeans). So a fast and lightweight
 implementation for this special purpose would be interesting.
 
 Oliver
 
 
 Am 04.11.2014 um 15:55 schrieb Jochen Wiedmann:
  Hi,
 
  As some of you (hopefulyl not all) may have noticed, have added a
  project called Commons Inject to the Sandbox [1] today. Commons Inject
  is a JSR 330 compliant dependency injection framework. It is something
  I had in the works for quite some time, but now it has reached a
  decent state with my preliminary milestones reached:
 
  - Passes the JSR 330 TCK.
  - Integrated lifecycle handling via @PostConstruct and @PreDestroy.
  Works with all scopes,
including lazy singletons. (I never got this to work with Guice,
  which has been my major
driver for doing this.)
  - Integrated logger injection framework for Log4J, SLF4J, and Commons
  Logging. Others can
easily be added.
 
  I intend to use this for serious works from now on and consequently
  hope to create a release real soon, at which point I'll ask to move
  this to proper.
 
  Any feedback welcome.
 
  Jochen
 
  [1] https://svn.apache.org/viewvc/commons/sandbox/commons-inject/trunk/
 
 
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org
 

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

Re: Announce: Commons Inject

[Mark Struberg]

 - I'm under the impression there are already well established
 implementations of JSR 330

Well, the problem I see with this very approach is that it says it 'implements 
JSR-330'.
As an EG member I can tell you that atinject is only the least common 
denominator of the 'user side' of the story. It totally misses how those beans 
get created, how the scoped are filled, etc. It's really just the common part 
of Spring, CDI, Guice and EJB. 

That's basically like specifying a 'book' as a piece with pages with written 
words on it and packaged in a cover. This definition is fine for storing books 
in a library but it doesn't say anything about the content.

A concrete example: atinject defines @Scope. But how does those beans behave? 
How do they get stored and how do they get produced? Atinject defines none of 
those aspects. You would need to invent all of pieces on that side yourself.

Otoh OpenWebBeans core defines all this via CDI and has about 450k. Plus a few 
spec api jars which are not large neither. And this is not even specially 
trimmed down. We might be able to remove even more stuff (we did not try yet). 
There is also the possibility to e.g. switch our our default ScannerService and 
use one where you hand over the classes you like to use via a SetClass.

In the CDI EG we also currently experimenting with trimming down the 
functionality of CDI for pure CDI usage by e.g. trimming all the bytecode 
tinkering. We'd be happy to not only get feedback but also about additional 
helping hands ;)


LieGrue,
strub




- Original Message -
 From: Phil Steitz phil.ste...@gmail.com
 To: Commons Developers List dev@commons.apache.org
 Cc: 
 Sent: Saturday, 8 November 2014, 22:03
 Subject: Re: Announce: Commons Inject
 
 On 11/4/14 9:08 AM, Emmanuel Bourg wrote:
  Le 04/11/2014 15:55, Jochen Wiedmann a écrit :
 
  Any feedback welcome.
  Hi Jochen,
 
  I'm not a dependency injection expert so I can't really comment on 
 the
  design, I could just make trivial observations like the use of the 
 'I'
  prefix for the interfaces which isn't used in the commons components 
 and
  may lead to some confusing names (IMutableBindingSource is not immutable).
 
  I'm more concerned by the viability of this project as a Apache Commons
  component:
  - Are there other committers interested in maintaining this project?
 
 That's the right question to ask.
  - Will this be used by other Apache projects? I tend to see Apache
  Commons as the place to factorize common code used across Apache
  projects, I'm not sure it works very well in the other direction.
 
 Well, [math] is one example of a component that started here and it
 has done OK.  I suspect most usage of [lang], [collections],
 [configuration] and quite a few others are outside apache as well at
 this point.  
  - I'm under the impression there are already well established
  implementations of JSR 330, what was the motivation behind this
  implementation? What are the selling points of this implementation
  compared to the others?
 
 Always a good question to ask, but not a blocker.   Each time we
 start a new JSR-blah thing at the ASF you can ask the same
 question.  Whoever wants to grow a community around the new thing
 has to be able to find some shared itches to make it interesting.
 Ollie mentioned one thing.  Maybe there are others.
  - Why bringing this in Apache Commons instead of starting on Github?
 
 Because we have the sandbox here as a place for committers to
 experiment with new components.  We all see what is going on there,
 so starting there also increases the chance that some other commons
 committers will get interested in the new thing.
 
 Phil
 
  Emmanuel Bourg
 
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
  For additional commands, e-mail: dev-h...@commons.apache.org
 
 
 
 
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org


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

Re: Announce: Commons Inject

[Mark Struberg]

 Sorry, did not mean to step on somebody's toes.

No worries you didn't. It's most probably our fault as our (OpenWebBeans) 
documentation sucks and we did not properly document all this stuff ;)

If one of you guys is at ApacheCon in Budapest right now, then I'd love to give 
you a quick rush through our code an see if there is something you could use 
and also if we could improve something in OWB.

LieGrue,
strub




- Original Message -
 From: Oliver Heger oliver.he...@oliver-heger.de
 To: Commons Developers List dev@commons.apache.org
 Cc: 
 Sent: Sunday, 9 November 2014, 11:45
 Subject: Re: Announce: Commons Inject
 
 
 
 On 08.11.2014 21:51, Romain Manni-Bucau wrote:
  Le 8 nov. 2014 19:51, Oliver Heger 
 oliver.he...@oliver-heger.de a écrit
  :
 
  Hi Jochen,
 
  do you intend to position this framework for specific use cases? In
  which way is it different or special from other implementations?
 
  Just as one example: In the company I am working for, we are using CDI
  in a pretty large JSE application. Due to the huge class path the setup
  of the CDI container takes a long time and consumes a lot of memory
  (tested with both Weld SE and OpenWebBeans). So a fast and lightweight
  implementation for this special purpose would be interesting.
 
 
  Surely a bad example since you can achieve it with owb, just configure the
  scanner service
 
 Sorry, did not mean to step on somebody's toes.
 
 Oliver
 
 
  Oliver
 
  Am 04.11.2014 um 15:55 schrieb Jochen Wiedmann:
  Hi,
 
  As some of you (hopefulyl not all) may have noticed, have added a
  project called Commons Inject to the Sandbox [1] today. Commons 
 Inject
  is a JSR 330 compliant dependency injection framework. It is 
 something
  I had in the works for quite some time, but now it has reached a
  decent state with my preliminary milestones reached:
 
  - Passes the JSR 330 TCK.
  - Integrated lifecycle handling via @PostConstruct and @PreDestroy.
  Works with all scopes,
 including lazy singletons. (I never got this to work with Guice,
  which has been my major
 driver for doing this.)
  - Integrated logger injection framework for Log4J, SLF4J, and 
 Commons
  Logging. Others can
 easily be added.
 
  I intend to use this for serious works from now on and consequently
  hope to create a release real soon, at which point I'll ask to 
 move
  this to proper.
 
  Any feedback welcome.
 
  Jochen
 
  [1] 
 https://svn.apache.org/viewvc/commons/sandbox/commons-inject/trunk/
 
 
 
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
  For additional commands, e-mail: dev-h...@commons.apache.org
 
 
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org


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

Re: Announce: Commons Inject

[Mark Struberg]

Jochen, I might have done something wrong so please help me.

I've checked out your svn link and built it. 

Then I did a 

$ mvn clean -DincludeScope=runtime dependency:copy-dependencies
-rw-r--r--+ 1 struberg staff4467 19. Nov 08:41 aopalliance-1.0.jar
-rw-r--r--+ 1 struberg staff 2228009 19. Nov 08:41 guava-16.0.1.jar
-rw-r--r--+ 1 struberg staff  642741 19. Nov 08:41 guice-4.0-beta5.jar
-rw-r--r--+ 1 struberg staff2497 19. Nov 08:41 javax.inject-1.jar


$ du -hs target/dependencies 

show me 2.8 MB


Plus your own jar which is 76k.
Is there something wrong? What are you using guice and guava for?
Also there is an own ASF package for atinject [1].

LieGrue,
strub



[1] 
http://repo1.maven.org/maven2/org/apache/geronimo/specs/geronimo-atinject_1.0_spec/1.0/




On Wednesday, 19 November 2014, 8:34, Mark Struberg strub...@yahoo.de wrote:
 Sorry, did not mean to step on somebody's toes.

No worries you didn't. It's most probably our fault as our (OpenWebBeans) 
documentation sucks and we did not properly document all this stuff ;)

If one of you guys is at ApacheCon in Budapest right now, then I'd love to 
give you a quick rush through our code an see if there is something you could 
use and also if we could improve something in OWB.

LieGrue,
strub




- Original Message -
 From: Oliver Heger oliver.he...@oliver-heger.de
 To: Commons Developers List dev@commons.apache.org
 Cc: 
 Sent: Sunday, 9 November 2014, 11:45
 Subject: Re: Announce: Commons Inject
 
 
 
 On 08.11.2014 21:51, Romain Manni-Bucau wrote:
  Le 8 nov. 2014 19:51, Oliver Heger 
 oliver.he...@oliver-heger.de a écrit
  :
 
  Hi Jochen,
 
  do you intend to position this framework for specific use cases? In
  which way is it different or special from other implementations?
 
  Just as one example: In the company I am working for, we are using CDI
  in a pretty large JSE application. Due to the huge class path the setup
  of the CDI container takes a long time and consumes a lot of memory
  (tested with both Weld SE and OpenWebBeans). So a fast and lightweight
  implementation for this special purpose would be interesting.
 
 
  Surely a bad example since you can achieve it with owb, just configure the
  scanner service
 
 Sorry, did not mean to step on somebody's toes.
 
 Oliver
 
 
  Oliver
 
  Am 04.11.2014 um 15:55 schrieb Jochen Wiedmann:
  Hi,
 
  As some of you (hopefulyl not all) may have noticed, have added a
  project called Commons Inject to the Sandbox [1] today. Commons 
 Inject
  is a JSR 330 compliant dependency injection framework. It is 
 something
  I had in the works for quite some time, but now it has reached a
  decent state with my preliminary milestones reached:
 
  - Passes the JSR 330 TCK.
  - Integrated lifecycle handling via @PostConstruct and @PreDestroy.
  Works with all scopes,
 including lazy singletons. (I never got this to work with Guice,
  which has been my major
 driver for doing this.)
  - Integrated logger injection framework for Log4J, SLF4J, and 
 Commons
  Logging. Others can
 easily be added.
 
  I intend to use this for serious works from now on and consequently
  hope to create a release real soon, at which point I'll ask to 
 move
  this to proper.
 
  Any feedback welcome.
 
  Jochen
 
  [1] 
 https://svn.apache.org/viewvc/commons/sandbox/commons-inject/trunk/
 
 
 
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
  For additional commands, e-mail: dev-h...@commons.apache.org

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


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




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

Re: [jcs] What's next?

[Mark Struberg]

Well my personal experience only:


1.) I barely use distributed caches. I use ehcache in most of my projects as of 
today, but do not use the distribution feature much. Way too complicated

2.) What actually IS useful is distributed cache invalidation. The caching side 
is fine to just select any values from my DB if they are not yet cached. But if 
I change those values, then I really need some ways to get rid of the values in 
all the caches on all my cluster nodes.

So from a purely personal point I would favour a mode which is really fast as a 
local cache but would have some ways to distribute the invalidation of a cache 
to all other nodes.

Not sure how this fits into jcs - don't know the codebase well enough to judge 
about it.

LieGrue,
strub


On Tuesday, 6 May 2014, 13:29, Romain Manni-Bucau rmannibu...@gmail.com wrote:
 
Here some pseudo-core details about my first mail:

New internals:
* NetworkTopology
* EntryRepartitor: compute the index of the
* Node (LocalNode which is current impl and RemoteNode which is just a
remote facade relying Network)

NetworkTopology { // impl using udp/tcp/or whatever
     Node[] findAll() // used by a background thread to check if there
is a new node and if so rebalance the cluster
}

Node { // remote and local API
     get(k), put(k, v)  (CacheK, V primitive methods)
     Statistics getStatistics() // used by a background thread to
aggregate stats on each node
}


EntryRepartitor {
     Node[] nodeAndBackups(key)
}


get(key) { // symmetrical for put of course
    Node[] nodes = entryRepartitor.nodeAndBackups(key);
    for (final Node node : nodes) {
         try {
             return node.get(key);
         } catch(final RemoteCacheException rce) { // API exception
             throw rce.getJCacheException();
         } catch(final Exception e) { // network exception try next node
            // continue
         }
    }
}

Of course we'll get LocalNode implementing Node with the current impl
(ConcurrentHashMap) and RemoteNode will be a client view of the
LocalNode over the network.

To keep it testable we need to be able to test a RemoteNode -
LocalNode connection in the same JVM creating manually two
CachingProviders.

wdyt?


Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau



2014-05-06 12:50 GMT+02:00 Romain Manni-Bucau rmannibu...@gmail.com:
 FYI I attached a patch using a ConcurrentHashMap here
 https://issues.apache.org/jira/browse/JCS-127

 It is pretty fast compared to previous impl.


 Romain Manni-Bucau
 Twitter: @rmannibucau
 Blog: http://rmannibucau.wordpress.com/
 LinkedIn: http://fr.linkedin.com/in/rmannibucau
 Github: https://github.com/rmannibucau


 2014-05-06 8:31 GMT+02:00 Romain Manni-Bucau rmannibu...@gmail.com:
 Hi guys,

 few questions about jcs:

 1) I played a bit with remote cache server etc and didn't find a lot
 of use cases, do we keep it this way (linked to 4) )?
 2) API: do we use JCache as main API or do we keep core?
 3) Reviewing JCache module I really wonder if we shouldn't use a
 ConcurrentHashMap instead of a the currently backing CompositeCache
 and add on top of this locally optimized implementation two things:
 a) eviction (a thread regularly iterating over local items to check
 expiry would be enough), b) distribution (see 4) )
 4) distributed mode: I wonder if we shouldn't rethink it and
 potentially add CacheK, V listeners usable in JCache to know if
 another node did something (useful to get consistent stats at least -
 basically we need a way to aggregate on each note stats) + use a key
 for each node to keep data on a single node + potentially add backup
 on another node.

 wdyt?

 I don't know how much JCS is used ATM and if we can break that much
 the API but since that would be a 2.0 I think it is the moment


 Romain Manni-Bucau
 Twitter: @rmannibucau
 Blog: http://rmannibucau.wordpress.com/
 LinkedIn: http://fr.linkedin.com/in/rmannibucau
 Github: https://github.com/rmannibucau

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

Re: [jcs] building with JSR-107 TCK

[Mark Struberg]

Weird, it compiles on my box (Oracle1.7 and 1.8 on Mac) and I get another 
compile error with Apple java-1.6.0_65


Have to finish a presentation till monday and work on BatchEE for $$dayjob. So 
I will only be able to help again starting with Thuesday.

LieGrue,
strub




 On Friday, 2 May 2014, 16:21, Thomas Vandahl t...@apache.org wrote:
  On 02.05.14 10:13, Jean-Louis MONTEIRO wrote:
  He he, sure :)
 
  Here is the error even in Java 7.
  ERROR]
 
 /Users/jlmonteiro/devs/asf/commons/proper/jcs/trunk/commons-jcs-jcache/src/main/java/org/apache/commons/jcs/jcache/JCSCache.java:[92,129]
  cannot find symbol
    symbol:   class MyThreadFactory
    location: class org.apache.commons.jcs.utils.threadpool.ThreadPoolManager
  [ERROR]
 
 /Users/jlmonteiro/devs/asf/commons/proper/jcs/trunk/commons-jcs-jcache/src/main/java/org/apache/commons/jcs/jcache/JCSCache.java:[93,68]
  cannot find symbol
    symbol:   class MyThreadFactory
    location: class org.apache.commons.jcs.utils.threadpool.ThreadPoolManager
 
 Yeah, I removed the thread factories that were scattered all over the
 place and created a separate class. I did some other stuff so I could
 not commit everything. It will be fixed soon.
 
 
 Bye, Thomas.
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org


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

Re: [ALL] Suppressing Javadoc errors with Java 8 - temporary hack

[Mark Struberg]

Hi!

It turned out that it is always just a bit more complicated.
Romain detected that building OpenWebBeans with Java8 did lead to bytecode 
which does not work on ANY older JVM. The reason is that methods of 
ConcurrentHashMap (and possibly other) has been moved to an Interface. See 
OWB-952 [1] for more info.

This is ok and a known aspect from a general JVM perspective [2] but needs some 
caution on our side. Which also means that any TCK, unit tests whatever are NOT 
sufficient to prove backward compat with older platforms nor that it works on 
newer platforms.

My personal summary is that if we like to support java6 in commons-jcs, then we 
should really run the release with a jdk-1.6.


LieGrue,
strub



[1] https://issues.apache.org/jira/browse/OWB-952
[2] https://blogs.oracle.com/darcy/entry/how_to_cross_compile_for





 On Thursday, 1 May 2014, 18:27, Bernd Eckenfels e...@zusammenkunft.net 
 wrote:
  Am Thu, 1 May 2014 11:01:32 -0500
 schrieb Paul Benedict pbened...@apache.org:
 
  Wrong syntax is different than missing syntax. The former affects
  readability while the other just affects usability. Glad you found a
  way to catch the former but ignore the latter.
 
 I agree with the missing should be warning, but I don't see a 
 need to
 change the configuration. I just fixes the self-closed errors in 
 VFS2
 with javadoc8 and it now builds with no errors. It soes show missing
 @param @return and @throws but they are all warnings.
 
 It is using commons-vfs2-project:2.1-SNAPSHOT which is using
 commons-parent:32 and none of those define Javadoc lint options (only
 quiet=true).
 
 So I am not sure why you need to change the parents?
 
 
 I do see a problem with additional @todo tags. They are configured in
 the project parent, but it seems from the effective pom that they are
 not used in all invocations, at least they made the build fail (and I
 wrongly corrected them).
 
 Bernd
 
 
 
 
  On Thu, May 1, 2014 at 5:22 AM, Mark Struberg strub...@yahoo.de
  wrote:
 
   Actually the ',' causes a bug in the maven-javadoc-plugin. 
 What
   seems to work is to split it into 2 parts:
  
   additionalparam-Xdoclint:all 
 -Xdoclint:-missing/additionalparam
  
   Already started a discussion about adding it to apache-parent over
   in maven-dev.
  
   LieGrue,
   strub
  
  
  
  
  
  
  
On Thursday, 1 May 2014, 11:05, Mark Struberg 
 strub...@yahoo.de
wrote:
 I would prefer it if the reports were warnings rather 
 than
 errors, but
generally they seem sensible.
   
   
Allow me to disagree. Breaking the javadoc just because a @param
is
   missing is
imo plain wrong.
   
Usually parameters should be self-explaining. I personally only
document interfaces and methods where it is *not* clear what the
params intend.
   
   
Please don't let us end up with tons of unnecessary (because
obvious) Javadocs just to make java8 happy.
   
I've done some research and asked some Java8 devs I know. 
 Seems
   

 additionalparam-Xdoclint:all,-missing/additionalparam
   
could do the trick. Still need to test it though.
   
We should btw add this to the apache-parent pom and not only to
   commons-parent.
   
LieGrue,
strub
   
   
   
   
   
On Wednesday, 16 April 2014, 20:51, sebb seb...@gmail.com 
 wrote:
   
On 16 April 2014 19:32, Gary Gregory 
 garydgreg...@gmail.com
wrote:
     I personally like the default Java 8 behavior and I 
 would not
want to disable it.
   
I would prefer it if the reports were warnings rather than
errors, but generally they seem sensible.
   
-1 to adding it to the parent POM as a default.
It might have been OK to do so if it were possible to 
 activate
it only when Java 8 is being used to a component that targets
Java 5,6,7. But suppressing DocLint for source that targets 
 Java
8 seems a very bad
idea.
Unfortunately ANDed activation conditions for profiles are
borked and have been for ages.
   
I think it's OK to use in component POMs because each 
 component
will be different.
And it can be easily removed when the source has been 
 updated.
   
     Gary
   
   
     On Wed, Apr 16, 2014 at 1:06 PM, Matt Benson
gudnabr...@gmail.com wrote:
   
     I think the implication was that adding it to the 
 parent POM
would
not
     encourage us to actually *solve* the underlying 
 issue. ;)
   
     Matt
   
   
     On Wed, Apr 16, 2014 at 12:02 PM, Emmanuel Bourg
ebo...@apache.org
     wrote:
   
      Le 16/04/2014 18:41, sebb AT ASF a écrit :
       See below for one way to automatically 
 suppress Javadoc
errors when
       running under Java 8
      
       It should not be adopted as a permanent 
 measure, but may
be useful
       whilst Javadoc is being fixed.
     
      Can we add that to the parent pom?
     
      Emmanuel Bourg

Re: Apache Commons ApacheCon Europe 2014 ...

[Mark Struberg]

what about commons lightning talks?
5 minutes about a certain commons feature.
There are plenty to choose from...

LieGrue,
strub


On Friday, 2 May 2014, 10:28, Siegfried Goeschl sgoes...@gmx.at wrote:
 
Hi Benedikt,

there might be a lot of different kinds there :-)

IMHO the problem with Let people tell us, what they like about lang and 
what they don't like is that your presentation depends on the input of 
the attendees and the presentation setup (good for a small room but bad 
if you have a large room).

One option could for the presentation could be picking common problems 
and how they are solved with commons-lang

* Variable expansion using StrSubstitutor
* Dumping third-party objects using ReflectionToStringBuilder
* StopWatch for mirco-benchmarks

Cheers,

Siegfried Goeschl


On 02.05.14 09:46, Benedikt Ritter wrote:
 2014-04-30 21:24 GMT+02:00 Siegfried Goeschl siegfried.goes...@it20one.com
 :

 Hi folks,

 I collected the responses/feedback so far sorted according to the given
 committment

 Commons SCXML - Ate Douma - will present
 Commons Email - Siegfried Goeschl - will present

 Commons Math - Thomas Neidhart - likely to present (depending on personal
 plans)
 Commons Collections - Thomas Neidhart - likely to present (depending on
 personal plans)
 Commons JCS - Thomas Vandahl - would like to present depending on the JCS
 2.0 release
 Commons VFS - Schalk W. Cronjé - would like to present

 Commons Compress - Stefan Bodewig - might be interested
 Commons Exec - Siegfried Goeschl - can give a presentation if feasible
 Commons CLI - Siegfried Goeschl - can give a presentation if feasible but
 I’m only a user

 So far

 * IMHO the Apache Commons Community should be able to present 5-6
 components which would fill 3 regular slots
 * I would really appreciate if more developers would volunteer for a
 component - it is a great experience to present at a conference :-)

 I'm interested to present something. Since I work mostly on commons-lang
 that would be the component I could talk about. Problem is, I don't really
 know what kind of talk people a interested in. commons-lang has been around
 for a long time know and there isn't really something special about it.

 I'm wondering if it is possible to use a slot for a discussion or
 something. Let people tell us, what they like about lang and what they
 don't like. This could lead to some ideas for the design of 4.0 which I'm
 planning to start latter this year.

 Benedikt


 Cheers,

 Siegfried Goeschl


 On 28 Apr 2014, at 22:59, Thomas Neidhart thomas.neidh...@gmail.com
 wrote:

 On 04/17/2014 04:02 PM, Siegfried Goeschl wrote:
 Hi folks,

 thanks to Phil and Ate to present Apache Commons at the ApacheCon in
 Denver :-)
 I would like to follow up the idea of having a dedicated Apache Commons
 slots for ApacheCon Europe as we have done it in Atlanta
 * give the Apache Commons committers the chance to present at ApacheCon
 while NOT working in BigData, Hadoop or NoSQL
 * use a regular 45 minutes slot to present two Apache Commons
 components assuming that many components are rather small
 * present a couple of Apache Commons component within a dedicated block
 of slots (conference within the conference)
 * I chatted with Ate Douma about it and he in turn chatted with other
 guys so I think this idea is in general appreciated
 So the questions are

 * Is this idea appreciated?
 * Who would volunteer for presenting his/her Apache Commons component?
 I would be interested to go there and give a talk about some components
 I am contributing to, like math and collections.

 Can not give a guarantee yet, as I might be occupied for personal
 reasons in November.

 Thomas

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



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





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

Re: JDK8 compatible javadoc

[Mark Struberg]

-Xdoclint:all -Xdoclint:-missing -Xdoclint:-html

That should fix the issue. 
ATTN: this must ONLY be done in a java8 profile! If you set those params in 
older java versions (1.7, 1.6) then the build will blow up...

LieGrue,
strub


On Wednesday, 30 April 2014, 7:47, Paul Benedict pbened...@apache.org wrote:
 
Looks like I found the message I alluded to. Make sure you read the whole
thread for fun ;-)
http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/019269.html



On Wed, Apr 30, 2014 at 12:36 AM, Thomas Neidhart thomas.neidh...@gmail.com
 wrote:

 On 04/30/2014 03:50 AM, Gary Gregory wrote:
  Well, it does not support HTML in the sense that you MUST close all tags.
  No lonely ps...

 Unless something has changed for jdk8, lonely ps are supported and
 even advertised like this in the main javadoc guide from Sun/Oracle:


 http://www.oracle.com/technetwork/java/javase/documentation/index-137868.html

 Also there are components like collections that heavily rely on this.

 Thomas

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




-- 
Cheers,
Paul

Re: JDK8 compatible javadoc

[Mark Struberg]

so it would be nice if our components do compile and work on Java 8

It does of course. But if you compile with java8 then it _might_ not work with 
older java versions. So it's fine for packages built by Fedora FOR Fedora. But 
those jars might not work on any other linux distro. Which is ok from the Linux 
distro side, but a bit unexpected from a Java perspective...

LieGrue,
strub



On Friday, 2 May 2014, 15:44, Emmanuel Bourg ebo...@apache.org wrote:

Le 02/05/2014 15:37, Gary Gregory a écrit :
 So the plan is to let each [component] pick how they want to deal with Java
 8 right?

As a side note, I'd like to emphasize that our source code is being
recompiled by downstream packagers, most notably Linux distributions.
Fedora 21 will default to Java 8 and Debian is working toward this goal,
so it would be nice if our components do compile and work on Java 8. For
now math, exec and bcel aren't working properly.

Emmanuel Bourg



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





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

[jcs] building with JSR-107 TCK

[Mark Struberg]

Hi folks!

I've moved the TCK run into an own profile. You can activate it via

$ mvn clean install -PjcacheTck

We should also activate it by default during a release.

Btw, why is this project target 1.7? We do not use anything from java7 right?


LieGrue,
strub

Re: [ALL] Suppressing Javadoc errors with Java 8 - temporary hack

[Mark Struberg]

I would prefer it if the reports were warnings rather than errors, but
generally they seem sensible.


Allow me to disagree. Breaking the javadoc just because a @param is missing is 
imo plain wrong.

Usually parameters should be self-explaining. I personally only document 
interfaces and methods where it is *not* clear what the params intend. 


Please don't let us end up with tons of unnecessary (because obvious) Javadocs 
just to make java8 happy.

I've done some research and asked some Java8 devs I know. Seems

additionalparam-Xdoclint:all,-missing/additionalparam

could do the trick. Still need to test it though.

We should btw add this to the apache-parent pom and not only to commons-parent.

LieGrue,
strub





On Wednesday, 16 April 2014, 20:51, sebb seb...@gmail.com wrote:

On 16 April 2014 19:32, Gary Gregory garydgreg...@gmail.com wrote:
 I personally like the default Java 8 behavior and I would not want to
 disable it.

I would prefer it if the reports were warnings rather than errors, but
generally they seem sensible.

-1 to adding it to the parent POM as a default.
It might have been OK to do so if it were possible to activate it only
when Java 8 is being used to a component that targets Java 5,6,7.
But suppressing DocLint for source that targets Java 8 seems a very bad idea.
Unfortunately ANDed activation conditions for profiles are borked and
have been for ages.

I think it's OK to use in component POMs because each component will
be different.
And it can be easily removed when the source has been updated.

 Gary


 On Wed, Apr 16, 2014 at 1:06 PM, Matt Benson gudnabr...@gmail.com wrote:

 I think the implication was that adding it to the parent POM would not
 encourage us to actually *solve* the underlying issue. ;)

 Matt


 On Wed, Apr 16, 2014 at 12:02 PM, Emmanuel Bourg ebo...@apache.org
 wrote:

  Le 16/04/2014 18:41, sebb AT ASF a écrit :
   See below for one way to automatically suppress Javadoc errors when
   running under Java 8
  
   It should not be adopted as a permanent measure, but may be useful
   whilst Javadoc is being fixed.
 
  Can we add that to the parent pom?
 
  Emmanuel Bourg
 
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
  For additional commands, e-mail: dev-h...@commons.apache.org
 
 




 --
 E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
 Java Persistence with Hibernate, Second 
 Editionhttp://www.manning.com/bauer3/
 JUnit in Action, Second Edition http://www.manning.com/tahchiev/
 Spring Batch in Action http://www.manning.com/templier/
 Blog: http://garygregory.wordpress.com
 Home: http://garygregory.com/
 Tweet! http://twitter.com/GaryGregory


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




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

Re: [ALL] Suppressing Javadoc errors with Java 8 - temporary hack

[Mark Struberg]

Actually the ',' causes a bug in the maven-javadoc-plugin. What seems to work 
is to split it into 2 parts:

additionalparam-Xdoclint:all -Xdoclint:-missing/additionalparam

Already started a discussion about adding it to apache-parent over in maven-dev.

LieGrue,
strub







 On Thursday, 1 May 2014, 11:05, Mark Struberg strub...@yahoo.de wrote:
  I would prefer it if the reports were warnings rather than errors, but
 generally they seem sensible.
 
 
 Allow me to disagree. Breaking the javadoc just because a @param is missing 
 is 
 imo plain wrong.
 
 Usually parameters should be self-explaining. I personally only document 
 interfaces and methods where it is *not* clear what the params intend. 
 
 
 Please don't let us end up with tons of unnecessary (because obvious) 
 Javadocs just to make java8 happy.
 
 I've done some research and asked some Java8 devs I know. Seems
 
 additionalparam-Xdoclint:all,-missing/additionalparam
 
 could do the trick. Still need to test it though.
 
 We should btw add this to the apache-parent pom and not only to 
 commons-parent.
 
 LieGrue,
 strub
 
 
 
 
 
 On Wednesday, 16 April 2014, 20:51, sebb seb...@gmail.com wrote:
 
 On 16 April 2014 19:32, Gary Gregory garydgreg...@gmail.com wrote:
  I personally like the default Java 8 behavior and I would not want to
  disable it.
 
 I would prefer it if the reports were warnings rather than errors, but
 generally they seem sensible.
 
 -1 to adding it to the parent POM as a default.
 It might have been OK to do so if it were possible to activate it only
 when Java 8 is being used to a component that targets Java 5,6,7.
 But suppressing DocLint for source that targets Java 8 seems a very bad 
 idea.
 Unfortunately ANDed activation conditions for profiles are borked and
 have been for ages.
 
 I think it's OK to use in component POMs because each component will
 be different.
 And it can be easily removed when the source has been updated.
 
  Gary
 
 
  On Wed, Apr 16, 2014 at 1:06 PM, Matt Benson 
 gudnabr...@gmail.com wrote:
 
  I think the implication was that adding it to the parent POM would 
 not
  encourage us to actually *solve* the underlying issue. ;)
 
  Matt
 
 
  On Wed, Apr 16, 2014 at 12:02 PM, Emmanuel Bourg 
 ebo...@apache.org
  wrote:
 
   Le 16/04/2014 18:41, sebb AT ASF a écrit :
See below for one way to automatically suppress Javadoc 
 errors when
running under Java 8
   
It should not be adopted as a permanent measure, but may 
 be useful
whilst Javadoc is being fixed.
  
   Can we add that to the parent pom?
  
   Emmanuel Bourg
  
  
   
 -
   To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
   For additional commands, e-mail: dev-h...@commons.apache.org
  
  
 
 
 
 
  --
  E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
  Java Persistence with Hibernate, Second 
 Editionhttp://www.manning.com/bauer3/
  JUnit in Action, Second Edition 
 http://www.manning.com/tahchiev/
  Spring Batch in Action http://www.manning.com/templier/
  Blog: http://garygregory.wordpress.com
  Home: http://garygregory.com/
  Tweet! http://twitter.com/GaryGregory
 
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org
 
 
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org


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

Re: [jcs] building with JSR-107 TCK

[Mark Struberg]

Well, the TCK runs fine with source and target 1.6. There is nothing in our 
code which requires java7 yet. Thus there is imo no reason to force it. 

LieGrue,
strub





 On Thursday, 1 May 2014, 9:53, Mark Struberg strub...@yahoo.de wrote:
  Hi folks!
 
 I've moved the TCK run into an own profile. You can activate it via
 
 $ mvn clean install -PjcacheTck
 
 We should also activate it by default during a release.
 
 Btw, why is this project target 1.7? We do not use anything from java7 right?
 
 
 LieGrue,
 strub
 

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

Re: [jcs] building with JSR-107 TCK

[Mark Struberg]

Yes but source and target have been set to 1.7 in the parent pom.
Changed this back to 1.6 now.

LieGrue,
strub





 On Thursday, 1 May 2014, 13:03, Romain Manni-Bucau rmannibu...@gmail.com 
 wrote:
  wait think we didnt get each other - we say the same thing I think -,
 core and jcache module are built to target j6. Only tck module should
 run on j7/8. There are no other restriction and j6 is clearly targeted
 by jcache module.
 
 
 Romain Manni-Bucau
 Twitter: @rmannibucau
 Blog: http://rmannibucau.wordpress.com/
 LinkedIn: http://fr.linkedin.com/in/rmannibucau
 Github: https://github.com/rmannibucau
 
 
 
 2014-05-01 12:24 GMT+02:00 Mark Struberg strub...@yahoo.de:
  Well, the TCK runs fine with source and target 1.6. There is nothing in our 
 code which requires java7 yet. Thus there is imo no reason to force it.
 
  LieGrue,
  strub
 
 
 
 
 
  On Thursday, 1 May 2014, 9:53, Mark Struberg strub...@yahoo.de 
 wrote:
   Hi folks!
 
  I've moved the TCK run into an own profile. You can activate it via
 
  $ mvn clean install -PjcacheTck
 
  We should also activate it by default during a release.
 
  Btw, why is this project target 1.7? We do not use anything from java7 
 right?
 
 
  LieGrue,
  strub
 
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
  For additional commands, e-mail: dev-h...@commons.apache.org
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org
 

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

Re: [jcs] building with JSR-107 TCK

[Mark Struberg]

Hi!

I've looked at Continuum and it seems like it fails since weeks now.

Anyone successfully did run it with jdk-1.6?


If so, we should rather look at the Continuum config.


LieGrue,
strub





 On Thursday, 1 May 2014, 16:39, Thomas Vandahl t...@apache.org wrote:
  On 01.05.14 09:52, Mark Struberg wrote:
 
  Hi folks!
 
  I've moved the TCK run into an own profile. You can activate it via
 
  $ mvn clean install -PjcacheTck
 
  We should also activate it by default during a release.
 
  Btw, why is this project target 1.7? We do not use anything from java7 
 right?
 
 For some reason, The Test(TM) is failing again on Continuum. Is it
 possible that this has something to do with you latest modifications?
 
 One more question regarding the Continuum build. Obviously, the build
 deploys a snapshot into the snapshot repository. If you look at
 http://repository.apache.org/content/groups/snapshots/org/apache/commons/commons-jcs/2.0-SNAPSHOT/
 almost everything is there, just the jar is missing. Any idea why this
 happens?
 
 Bye, Thomas.
 
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org
 


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

Re: [jcs] jcache support?

[Mark Struberg]

Btw, fixed a few broken tests yesterday night, fixed the broken pom and added a 
few ALv2 license headers.

Now all builds fine on my local box (w java8).


LieGrue,
strub

On Tuesday, 29 April 2014, 22:20, Mark Struberg strub...@yahoo.de wrote:
 
plz folks do a full build before committing stuff next time.
Will fix the hamcrest deps now.

LieGrue,
strub



On Tuesday, 29 April 2014, 20:58, Thomas Vandahl t...@apache.org wrote:

On 28.04.14 20:55, Emmanuel Bourg wrote:
 Le 28/04/2014 20:44, Thomas Vandahl a écrit :
 
 This throws me out of the game. My Snow Leopard MacBook is 1.6 only.
 
 You can't upgrade it to Mavericks and install Java 7?

No I can't. MacBook One 32bit, you know.

Bye, Thomas.



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

Re: [jcs] jcache support?

[Mark Struberg]

Well, the TCK profile only gets activated on java7 - but I use java8 by default 
already...

Another point. The module needs to ALWAYS be included. And _inside_ the 
commons-jcs-tck-tests module we can just skip the tests if the 'tck' profile 
doesn't get activated. Otherwise we would screw up automatic versioning when 
releasing without having the tck activated.

LieGrue,
strub

On Wednesday, 30 April 2014, 8:46, Romain Manni-Bucau rmannibu...@gmail.com 
wrote:
 
well submitted a patch yesterday fixing 1 failling test (due to j7 or
j8) in core and fixing jcache module (my previous patch was not
totally applied), hopefully it is the same fix but here is the patch
https://issues.apache.org/jira/browse/JCS-120

when I updated this morning it was still broken


Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau


2014-04-30 8:26 GMT+02:00 Mark Struberg strub...@yahoo.de:
 Btw, fixed a few broken tests yesterday night, fixed the broken pom and 
 added a few ALv2 license headers.

 Now all builds fine on my local box (w java8).


 LieGrue,
 strub

 On Tuesday, 29 April 2014, 22:20, Mark Struberg strub...@yahoo.de wrote:

 plz folks do a full build before committing stuff next time.
Will fix the hamcrest deps now.

LieGrue,
strub



On Tuesday, 29 April 2014, 20:58, Thomas Vandahl t...@apache.org wrote:

On 28.04.14 20:55, Emmanuel Bourg wrote:
 Le 28/04/2014 20:44, Thomas Vandahl a écrit :

 This throws me out of the game. My Snow Leopard MacBook is 1.6 only.

 You can't upgrade it to Mavericks and install Java 7?

No I can't. MacBook One 32bit, you know.

Bye, Thomas.



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








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

Re: [jcs] jcache support?

[Mark Struberg]

plz folks do a full build before committing stuff next time.
Will fix the hamcrest deps now.

LieGrue,
strub


On Tuesday, 29 April 2014, 20:58, Thomas Vandahl t...@apache.org wrote:
 
On 28.04.14 20:55, Emmanuel Bourg wrote:
 Le 28/04/2014 20:44, Thomas Vandahl a écrit :
 
 This throws me out of the game. My Snow Leopard MacBook is 1.6 only.
 
 You can't upgrade it to Mavericks and install Java 7?

No I can't. MacBook One 32bit, you know.

Bye, Thomas.



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

Re: [VOTE] Release Apache Commons Weaver 1.0 based on RC1

[Mark Struberg]

+1

The poms don't include any groupId definitions.

Not needed and sometimes even a source of problems. If you do not need to write 
something than adding it only raises the chance it gets wrong.



 - The jar artifacts contain LICENSE and NOTICE without the .txt extension.
That's perfectly fine. All my ASF projects look that way. 


 - There is a bunch of checkstyle errors. For an initial release it 

 would be good to start with a clean code base.
I agree, but that's not a show stopper. Those are only warnings.


Regarding the mvn clean discussion: We could 'fix' this by using the 
maven-it-plugin. But that makes many things much more complicated to test and 
debug. Thus this is imo nothing we should address soon and all is fine imo. 


LieGrue,
strub


On Wednesday, 12 February 2014, 23:50, sebb seb...@gmail.com wrote:

On 12 February 2014 02:20, Matt Benson mben...@apache.org wrote:
 I would like to make the inaugural release of the [weaver] component.

 Apache Commons Weaver 1.0 RC1 is available for review at:
  https://dist.apache.org/repos/dist/dev/commons/weaver/ (r4368).

 Maven artifacts are at:
   https://repository.apache.org/content/repositories/orgapachecommons-1007/.

 Tested with Oracle JDKs 6 and 7.

 The Subversion tag is:
  
http://svn.apache.org/repos/asf/commons/proper/weaver/tags/1.0_RC1/(r1567477).

 Site:
  http://people.apache.org/~mbenson/commons-weaver-1.0-rc1/index.html

 RAT Report:
  http://people.apache.org/~mbenson/commons-weaver-1.0-rc1/rat-report.html


I've never seen the AL header in release notes before.
Not sure that's necessary (and it makes the notes harder to read).

The poms don't include any groupId definitions.
Although this will default from the parent, I think it is better to
specify the group id.
Otherwise it is not clear whether the omission is accidental or deliberate.
Also if the parent group Id ever changes (or perhaps is removed) the
component groupId will change unless the groupId is added at that
point.


 Keys: https://dist.apache.org/repos/dist/release/commons/KEYS

 Please review the release candidate and vote.
   This vote will close no sooner that 72 hours from now, i.e. after 0300UTC
 15-February 2014

   [ ] +1 Release these artifacts
   [ ] +0 OK, but...
   [ ] -0 OK, but really should fix...
   [ ] -1 I oppose this release because...

   Thanks!

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

Re: [VOTE] Promote [weaver] component out of sandbox

[Mark Struberg]

+1

LieGrue,
strub




- Original Message -
 From: Matt Benson gudnabr...@gmail.com
 To: dev@commons.apache.org
 Cc: 
 Sent: Friday, 20 September 2013, 19:49
 Subject: [VOTE] Promote [weaver] component out of sandbox
 
 Hi Commons developers,
   I hereby propose a vote to promote the [weaver] sandbox component to
 Commons proper.  My intent is that the promotion would be followed by a
 release of Apache Commons Weaver v1.0.
 
 This vote will be open for at least 72 hours.
 
 [ ] +1, Promote it!
 [ ] +0, Whatever
 [ ] -0, Meh
 [ ] -1, Keep it in the sandbox for now, and here's why:
 
 Thanks,
 Matt


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

Re: [proxy] and impl

[Mark Struberg]

JFTR: in Apache OpenWebBeans we switched to ASM because Javassist caused too 
much mem leaks and hassles. 

But we do only use reflection when it's really needed. Means methods which are 
neither delegated nor intercepted will delegated via native java calls. 
The same happens for 'NormalScoped' proxies (a CDI specialty) which only use 
pure java code and no reflection.

That said, a few figures: 10 million invocations on the proxies we generate 
using ASM (which do the getInstance() internally as well - ThreadLocal, Map 
lookup, etc) take 30ms on my notebook.

LieGrue,
strub




- Original Message -
 From: Romain Manni-Bucau rmannibu...@gmail.com
 To: Commons Developers List dev@commons.apache.org
 Cc: 
 Sent: Thursday, 1 August 2013, 17:15
 Subject: Re: [proxy] and impl
 
 hehe, do you have figures?
 
 when JIT did its work reflection is almost free. You can update the asm
 proxy factory to handle 3 implementations but it is not worth it IMO
 
 *Romain Manni-Bucau*
 *Twitter: @rmannibucau https://twitter.com/rmannibucau*
 *Blog: 
 **http://rmannibucau.wordpress.com/*http://rmannibucau.wordpress.com/
 *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
 *Github: https://github.com/rmannibucau*
 
 
 
 2013/8/1 James Carman ja...@carmanconsulting.com
 
  You're going to lose the benefit of having ASM if you just end up
  using reflection to call the methods anyway aren't you?  The Javassist
  code actually generates Java code that actually calls the real method
  on an instance of the appropriate type.  That's what makes it faster.
 
  On Thu, Aug 1, 2013 at 10:57 AM, Romain Manni-Bucau
  rmannibu...@gmail.com wrote:
   No, but believe me you want a handler (this one or invoker) to 
 maintain
  the
   code and keep it easy.
  
   *Romain Manni-Bucau*
   *Twitter: @rmannibucau https://twitter.com/rmannibucau*
   *Blog: **http://rmannibucau.wordpress.com/*
  http://rmannibucau.wordpress.com/
   *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
   *Github: https://github.com/rmannibucau*
  
  
  
   2013/8/1 Matt Benson gudnabr...@gmail.com
  
   That's my point; it doesn't.
  
  
   On Thu, Aug 1, 2013 at 9:49 AM, James Carman 
  ja...@carmanconsulting.com
   wrote:
  
Does the ASM API require a 
 java.lang.reflect.InvocationHandler?
   
On Thu, Aug 1, 2013 at 10:41 AM, Romain Manni-Bucau
rmannibu...@gmail.com wrote:
 Well for the maintainance it is easier (and not really 
 slower) to
  use a
 little abstraction. InvocationHandler/Inoker is fine. 
 Since JdkProxy
   uses
 the exact same code i throught it could be shared.

 *Romain Manni-Bucau*
 *Twitter: @rmannibucau 
 https://twitter.com/rmannibucau*
 *Blog: **http://rmannibucau.wordpress.com/*
http://rmannibucau.wordpress.com/
 *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
 *Github: https://github.com/rmannibucau*



 2013/8/1 Matt Benson gudnabr...@gmail.com

 The behavior of proxies is specified by Invokers, 
 ObjectProviders,
  and
 Interceptors. Each ProxyFactory implementation 
 bridges from these
 interfaces to the most appropriate mechanism 
 specific to the target
 technology. In the case of ASM, I would think that 
 would be direct
   calls
 against the proxy interface implementations 
 themselves.

 Matt
 On Aug 1, 2013 9:21 AM, Romain 
 Manni-Bucau 
  rmannibu...@gmail.com
 wrote:

 a sed shold almost work but the issue is the 
 same: the code is
 duplicated, no? is there invoker elsewhere?

 *Romain Manni-Bucau*
 *Twitter: @rmannibucau 
 https://twitter.com/rmannibucau*
 *Blog: **http://rmannibucau.wordpress.com/*
http://rmannibucau.wordpress.com/
 *LinkedIn: 
 **http://fr.linkedin.com/in/rmannibucau*
 *Github: https://github.com/rmannibucau*



 2013/8/1 Matt Benson 
 gudnabr...@gmail.com

 But is there some technical reason why 
 it's helpful for ASM
  proxies
   to
 use
 InvocationHandler specifically?  Why 
 wouldn't they just use
  Invoker
 directly?

 Matt


 On Thu, Aug 1, 2013 at 8:51 AM, Romain 
 Manni-Bucau 
 rmannibu...@gmail.comwrote:

  +1
 
  jdkproxyfactory can even be hardcoded 
 as a default IMO (without
using
 the
  SPI)
 
 
  *Romain Manni-Bucau*
  *Twitter: @rmannibucau 
 https://twitter.com/rmannibucau*
  *Blog: 
 **http://rmannibucau.wordpress.com/*
  http://rmannibucau.wordpress.com/
  *LinkedIn: 
 **http://fr.linkedin.com/in/rmannibucau*
  *Github: 
 https://github.com/rmannibucau*
 
 
 
  2013/8/1 James Carman 
 ja...@carmanconsulting.com
 
   You mean all the InvocationHandler 
 classes in JdkProxy?  I
  guess
we
   could break those out into 
 top-level classes, but then you'd
   have
   multiple implementations on your 
 classpath if you made a
dependency
 on
   commons-proxy-jdk.  We could 

Re: commons-monitoring?

[Mark Struberg]

Hi folks!

Romain is a great guy, I've now added him to commons-sandbox.

LieGrue,
strub




- Original Message -
From: James Carman ja...@carmanconsulting.com
To: Commons Developers List dev@commons.apache.org
Cc: 
Sent: Saturday, 27 July 2013, 3:46
Subject: Re: commons-monitoring?

On Fri, Jul 26, 2013 at 9:36 PM, Romain Manni-Bucau
rmannibu...@gmail.com wrote:
 Well we can discuss it in another thread but basically commons spirit for
 me is more basic and shouldn't be a facade (excepted logging). So i'd
 rather see proxy as an implementation of proxying using asm efficiently.
 The issue with proxying is not its lifecycle or API in general but its
 specificities (cache, proxy names, handlers...). The best solution IMO is
 to propose a unified solution which could be a facade but facade means all
 impl specificities in its API which makes it harder or specific (in v1
 instantiating the factory was a pain IMO since it is specific). ATM the
 question for me is always which one do i import depending my container, do
 i test against all proxies impl? Etc... it makes libs hard to write and
 maintain

Great feedback!  Please start another thread so we can discuss.

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

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

Re: [VOTE][LAZY] Release Commons Parent 32 from RC1

[Mark Struberg]

+1

LieGrue,
strub




- Original Message -
 From: sebb seb...@gmail.com
 To: dev@commons.apache.org
 Cc: 
 Sent: Friday, 28 June 2013, 14:18
 Subject: [VOTE][LAZY] Release Commons Parent 32 from RC1
 
T his is a VOTE to release Commons Parent 31-RC2
 
 This VOTE by LAZY-CONSENSUS is open for at least 72 hours
 It will finish no earlier than July 1 2013 at 14:00 GMT.
 
 The only change in this release is:
 - updated Javadoc plugin to 2.9.1 to fix Javadoc vulnerability
 (CVE-2013-1571, VU#225657) MJAVADOC-370
 
 The files:
 
 https://repository.apache.org/content/repositories/orgapachecommons-087/
 
 The tag:
 
 https://svn.apache.org/repos/asf/commons/proper/commons-parent/tags/commons-parent-32-RC1/
 
 The site: None.
 
 No need to vote unless you think there is a problem, in which case
 please vote -1 and explaing what the issue is.
 
 TIA!
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org
 

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

Re: commons-monitoring?

[Mark Struberg]

I'm not sure if this is needed in this case.

The Java interceptors spec got moved out of EJB a long time a go and is now a 
standalone spec which is used by CDI, Spring and guice.
The package is javax.interceptor and contains all the stuff we need.

If we do it in a similar style than Apache MyFaces CODI and now Apache 
DeltaSpike does it with the 'InterceptorStrategy' [1] then we are completely 
free of any container specific code.


LieGrue,
strub

[1] 
https://git-wip-us.apache.org/repos/asf?p=incubator-deltaspike.git;a=blob;f=deltaspike/core/api/src/main/java/org/apache/deltaspike/core/spi/InterceptorStrategy.java;h=a772152c46ae589572c6bb2bfb0292a8e980b2d3;hb=HEAD



- Original Message -
 From: Matt Benson gudnabr...@gmail.com
 To: Commons Developers List dev@commons.apache.org
 Cc: 
 Sent: Wednesday, February 13, 2013 4:39 PM
 Subject: Re: commons-monitoring?
 
 WRT a Commons Interceptor API, [proxy] defines Interceptor and other
 related interfaces.
 
 Matt
 
 
 On Wed, Feb 13, 2013 at 6:09 AM, Romain Manni-Bucau
 rmannibu...@gmail.comwrote:
 
  basically having a commons.Interceptor api can be interesting then we
  simply need to map to spring and cdi
 
  this is done in shiro for instance and works very well
 
  *Romain Manni-Bucau*
  *Twitter: @rmannibucau https://twitter.com/rmannibucau*
  *Blog: **http://rmannibucau.wordpress.com/*
  http://rmannibucau.wordpress.com/
  *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
  *Github: https://github.com/rmannibucau*
 
 
 
  2013/2/13 Benedikt Ritter brit...@apache.org
 
   2013/2/13 Paul Libbrecht p...@hoplahup.net
  
Benedikt,
   
On 13 févr. 2013, at 08:49, Benedikt Ritter wrote:
 Commons components usually don't have any dependencies. 
 How would you
 implement this under this restriction?
   
   
   
I've never seen this written before. Have you?
   
  
   Yes, on the commons website [1]:
  
   Commons developers will make an effort to ensure that their 
 components
   have minimal dependencies on other libraries, so that these components
  can
   be deployed easily.
  
   But you're right If you wanted to point out, that this is not an 
 absolute
   must-have. We can have minimal dependencies.
   I guess (but I don't know!) it would be okay to have a dependency 
 to the
   AOP alliance jars, for example to define a new MethodInterceptor [2] 
 for
   monitoring. But IMHO it would be rather strange to have dependencies 
 to
   org.springframework.aop to define a new MethodBeforeAdvice [3] for
   monitoring.
  
   Makes sense? :)
  
   Benedikt
  
   [1] http://commons.apache.org/
   [2]
  
  
 
 http://aopalliance.sourceforge.net/doc/org/aopalliance/intercept/MethodInterceptor.html
   [3]
  
  
 
 http://static.springsource.org/spring/docs/3.0.0.M1/javadoc-api/org/springframework/aop/MethodBeforeAdvice.html
  
  
   
paul
   
   
   
   
  
  
   --
   http://people.apache.org/~britter/
   http://www.systemoutprintln.de/
   http://twitter.com/BenediktRitter
   http://github.com/britter
  
 


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

Re: [weaver] SPI decisions

[Mark Struberg]

- Original Message -
 From: Matt Benson gudnabr...@gmail.com

 Weaver#weave():
 
   Currently there are separate methods for weaving a class vs. a method.  I
 think it would be sufficient and cleaner to have a class weaving method
 only; having provided its interests, the Weaver can presumably 
 figure out
 what to do with a class that has been determined to match. 

Yes that might be an option. I added it because sometimes you are interested in 
just a few methods as opposed to having to scan this all yourself (which is 
redundant because xbean-finder does it much more efficiently).


  Next, it feels
 a little odd to use a loaded Class instance to represent a class intended
 for modification.  Should we just use classname here?

Not sure, I need to look at the xbean-finder code. You need to parse the 
bytecode of the class for many things anyway and I don't think it will cause a 
file system lock. 


 
 Weaver#getInterest():
 
   Rather than providing ListClass? extends Annotation, I wonder 
 whether
 it would be more future-proof for this method (pluralized?) to return
 MapClass? extends Annotation, ElementType to say not only which
 Annotation types it is interested in, but where they are expected to be
 found.  This could work comfortably with the type of search registration
 APIs we've discussed for [classscan] in the future.

Yes we could go for it. There was just no need for it yet.


 Weaver#configure():
   This method supplies a target directory where classes are to be found.
 Perhaps too optimistically, I envision a future that could include a
 [weaver] ClassLoader to apply our advice at run, rather than build, time.
 Does anyone have any relevant experience that would guide us in providing
 the most flexible API to permit weaving of classfiles whether on the
 filesystem or otherwise?  Is it going too far to pull in [vfs] v2-core as a
 dependency?

I fear that might be a good bit of additional work to pull off. I'd rather go 
for a version with is working for now. We can still improve it later.

LieGrue,
strub


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

[privilizer] new idea to improve usability

[Mark Struberg]

Hi!

Not sure if this is worth doing, but could be nice from a usability pov.

Usually projects have a lot of blocks which need doPrivileged copied over from 
one class to the other.
Using @Privileged makes this a lot easier. But you still need to add private 
methods to all your classes...


Now imagine you have a public class SecurityUtil with methods having the 
annotation as in the example: 
public static @PrivilizerBlueprint ClassLoader getClassLoader() {..}

and on your other class where you like to use it you annotate the whole class 
with 

@UsingPrivilizerBlueprint(my.SecurityUtil.class)
public class MyOtherClass {
 public void doSomething() {
    ClassLoader cl = SecurityUtil.getClassLoader();
    ...
}


It would already be easy with the weaver to find all the classes which have a 
@UsingPrilizerBlueprint annotation. And it is also pretty easy to scan the 
bytecode and create private 'inlined' methods for all the @PrivilizerBlueprint 
methods (effectively copy over the bytecode for the whole method from the util 
class to the using class plus do the doPrivileged around it) and change the 
invocation from SecurityUtil.getClassLoader to this.privilized_getClassLoader()

In the afterWeave all the SecurityUtil methods which are just 
@PrivilizerBlueprint methods will get changed to Modifier private.


That would effectively reduce the need to manually add private methods to all 
your classes but instead maintain all those helper functions in a single well 
maintainable place.

If the weaver is disabled you would just use the SecurityUtil. Of course, from 
a debugging pov this is not that perfect, but from a writer/user pov it's a big 
benefit imo.



wdyt? worth trying?


LieGrue,
strub


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

Re: [commons-parent] drop cobertura

[Mark Struberg]

or just move it to a profile?
In our project we have this enabled via

$ mvn clean instal -Pcoverage

LieGrue,
strub




- Original Message -
 From: Luc Maisonobe luc.maison...@free.fr
 To: Commons Developers List dev@commons.apache.org
 Cc: 
 Sent: Saturday, December 29, 2012 9:43 AM
 Subject: Re: [commons-parent] drop cobertura
 
 Hi Phil,
 
 Le 28/12/2012 21:10, Phil Steitz a écrit :
  On 12/28/12 11:44 AM, Gary Gregory wrote:
  It seems a shame to turn off this feature for ALL projects because one
  project can't figure out a workaround.
 
  Can *any* project find a workaround?  Is there *any way* to turn
  this thing off?
 
 What about every project being declared in the aggregator project
 Olivier set up in our instance of Sonar
 https://analysis.apache.org/components/index/121254?
 
 Luc
 
 
  Phil
 
  Gary
 
  On Dec 28, 2012, at 12:21, Phil Steitz phil.ste...@gmail.com 
 wrote:
 
  Any objections to this?  In [math] at least we can't seem to 
 turn it
  off and it is causing the site build to take forever.
 
  Thanks!
 
  Phil
 
 
 -
  To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
  For additional commands, e-mail: dev-h...@commons.apache.org
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
  For additional commands, e-mail: dev-h...@commons.apache.org
 
 
 
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
  For additional commands, e-mail: dev-h...@commons.apache.org
 
 
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org


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

Re: [commons-parent] drop cobertura

[Mark Struberg]

 Any better suggestions for [math]?

Yes, as I see it there are two options.

a.) move some parts into a profile
b.) create 2 parent pom. One with the infrastructure stuff and one with all the 
tons of additional goodies only needed for the other projects.


LieGrue,
strub


PS: I find it pretty weird that the commons-parent has a profile to build all 
the other stuff. This can be done much cleaner in having an own 
build-aggregator pom which just contains the modules.


- Original Message -
 From: Phil Steitz phil.ste...@gmail.com
 To: Commons Developers List dev@commons.apache.org
 Cc: 
 Sent: Saturday, December 29, 2012 7:29 PM
 Subject: Re: [commons-parent] drop cobertura
 
 On 12/29/12 10:02 AM, Gary Gregory wrote:
  Using Sonar is an orthogonal issue to using reports in the POM. Sure, add
  commons components to Sonar, just do not mess up development for all the
  other components because one class in [math] is not performing acceptably
  for the Cobertura report.
 
 The problem is that the plugin is bugged and effectively impossible
 to turn off. 
 
 I think the sonar idea is a great one and consistent with what we
 have talked about on and off for years - separating the CI-type
 development reports from the component sites.  As we are about to go
 over the site deployment cliff ;  now is a great time to think
 about losing some weight :)
 
 I guess an alternative for [math] is to drop commons-parent
 entirely, just grabbing the stuff we need.  Any better suggestions
 for [math]?
 
 Phil
 
  Gary
 
 
  On Sat, Dec 29, 2012 at 12:55 PM, Phil Steitz phil.ste...@gmail.com 
 wrote:
 
  On 12/29/12 9:46 AM, Oliver Heger wrote:
  Am 29.12.2012 09:43, schrieb Luc Maisonobe:
  Hi Phil,
 
  Le 28/12/2012 21:10, Phil Steitz a écrit :
  On 12/28/12 11:44 AM, Gary Gregory wrote:
  It seems a shame to turn off this feature for ALL 
 projects
  because one
  project can't figure out a workaround.
  Can *any* project find a workaround?  Is there *any way* to 
 turn
  this thing off?
  What about every project being declared in the aggregator 
 project
  Olivier set up in our instance of Sonar
  https://analysis.apache.org/components/index/121254?
 
  +1
 
  We could then even disable more reports in the components' poms
  (findbugs, pmd, checkstyle, ...) and just add a link to the Sonar
  instance.
 
  This would provide comprehensive up-to-date statistics for all
  components. It would also be a step forward in making the
  components more uniform.
  +1 - and as yet another bonus, it would reduce wasted infra
  resources duplicating all of the images, etc on all of the
  individual sites and the need to store all of that stuff in svn.
 
  Phil
  Oliver
 
  Luc
 
  Phil
  Gary
 
  On Dec 28, 2012, at 12:21, Phil Steitz 
 phil.ste...@gmail.com
  wrote:
 
  Any objections to this?  In [math] at least we 
 can't seem to
  turn it
  off and it is causing the site build to take 
 forever.
 
  Thanks!
 
  Phil
 
 
 -
 
  To unsubscribe, e-mail: 
 dev-unsubscr...@commons.apache.org
  For additional commands, e-mail: 
 dev-h...@commons.apache.org
 
 
 -
 
  To unsubscribe, e-mail: 
 dev-unsubscr...@commons.apache.org
  For additional commands, e-mail: 
 dev-h...@commons.apache.org
 
 
 
 
 -
 
  To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
  For additional commands, e-mail: 
 dev-h...@commons.apache.org
 
 
 
 
 -
 
  To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
  For additional commands, e-mail: dev-h...@commons.apache.org
 
 
 
 -
  To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
  For additional commands, e-mail: dev-h...@commons.apache.org
 
 
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
  For additional commands, e-mail: dev-h...@commons.apache.org
 
 
 
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org


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

Re: commons-sandbox-parent needs some updates

[Mark Struberg]

Can anyone plz commit the pom upgrade for sandbox-parent?

https://issues.apache.org/jira/browse/SANDBOX-437

Need this for commons-weaver.

LieGrue,
strub




 From: Mark Struberg strub...@yahoo.de
To: Commons Developers List dev@commons.apache.org 
Sent: Saturday, December 22, 2012 3:58 PM
Subject: commons-sandbox-parent needs some updates
 
Hi!

Seems like our commons-sandbox-parent is stone old.

It points to a commons-parent-15 which is now 12 versions old ;)

I'll fix this, check a few problems which I had with the old version and ship 
a patch.


LieGrue,
strub

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





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

Re: [digester] dropping the annotations-processor module

[Mark Struberg]

I have no clue what the annotation processing is for, but might that be a 
candidate for the upcoming commons-weaver (formerly privilizer) ?
It takes CLASS/RUNTIME annotations a modifies the bytecode in the class 
directly.

LieGrue,
strub




- Original Message -
 From: Simone Tripodi simonetrip...@apache.org
 To: Commons Developers List dev@commons.apache.org
 Cc: 
 Sent: Friday, December 21, 2012 10:48 PM
 Subject: [digester] dropping the annotations-processor module
 
 Hi all guys!
 
 the annotations-processor module in Digester has been in a prototypal
 status for a long time and I haven't had time/chances to make it
 working, so, since it has never been released before and I am busy as
 heel and won't have the opportunity to work on it, unless someone
 submits a patch to DIGESTER-158, I would be for dropping it and make
 the build work (and possibly cut a release).
 
 Any objection?
 Many thanks in advance, all the best!
 -Simo
 
 http://people.apache.org/~simonetripodi/
 http://simonetripodi.livejournal.com/
 http://twitter.com/simonetripodi
 http://www.99soft.org/
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org
 

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

Re: [digester] dropping the annotations-processor module

[Mark Struberg]

 Does weaver enhances the class bytecode or even generate classes?

You could do both. Currently the only 'plugin' for the weaver is Matts 
privilizer. This one only 'enhances' an existing class. But there is no further 
restriction and I see no reason why you could not generate classes. But please 
note that this classes are only available _after_ the compilation. So they 
cannot (sanely) be referenced by any java source code.

LieGrue,
strub



- Original Message -
 From: Simone Tripodi simonetrip...@apache.org
 To: Commons Developers List dev@commons.apache.org
 Cc: 
 Sent: Saturday, December 22, 2012 1:16 PM
 Subject: Re: [digester] dropping the annotations-processor module
 
 Hi Mark!
 
 until v3.2 the Digester supported runtime annotations to generate the
 XML parser - the idea was having a processor that generates the XML
 parser at compile-time, but unfortunately I haven't had enough time to
 continue working on it...
 So, since it is even broken and still at the early stage, I propose to
 drop it to cut soon a new release, and postpone it to new versions.
 
 Does weaver enhances the class bytecode or even generate classes?
 
 TIA,
 -Simo
 
 http://people.apache.org/~simonetripodi/
 http://simonetripodi.livejournal.com/
 http://twitter.com/simonetripodi
 http://www.99soft.org/
 
 
 On Sat, Dec 22, 2012 at 10:45 AM, Mark Struberg strub...@yahoo.de wrote:
  I have no clue what the annotation processing is for, but might that be a 
 candidate for the upcoming commons-weaver (formerly privilizer) ?
  It takes CLASS/RUNTIME annotations a modifies the bytecode in the class 
 directly.
 
  LieGrue,
  strub
 
 
 
 
  - Original Message -
  From: Simone Tripodi simonetrip...@apache.org
  To: Commons Developers List dev@commons.apache.org
  Cc:
  Sent: Friday, December 21, 2012 10:48 PM
  Subject: [digester] dropping the annotations-processor module
 
  Hi all guys!
 
  the annotations-processor module in Digester has been in a prototypal
  status for a long time and I haven't had time/chances to make 
 it
  working, so, since it has never been released before and I am busy as
  heel and won't have the opportunity to work on it, unless someone
  submits a patch to DIGESTER-158, I would be for dropping it and make
  the build work (and possibly cut a release).
 
  Any objection?
  Many thanks in advance, all the best!
  -Simo
 
  http://people.apache.org/~simonetripodi/
  http://simonetripodi.livejournal.com/
  http://twitter.com/simonetripodi
  http://www.99soft.org/
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
  For additional commands, e-mail: dev-h...@commons.apache.org
 
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
  For additional commands, e-mail: dev-h...@commons.apache.org
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org
 

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

commons-sandbox-parent needs some updates

[Mark Struberg]

Hi!

Seems like our commons-sandbox-parent is stone old.

It points to a commons-parent-15 which is now 12 versions old ;)

I'll fix this, check a few problems which I had with the old version and ship a 
patch.


LieGrue,
strub

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

[weaver] blow up if access level is not correctly set

[Mark Struberg]

I changed the privilizer weaver to blow up with an Exception if an access level 
is set and a @Privileged method which has a wider accesslevel got detected.

Imo this is a clear user error if one defines a public @Privileged method and 
explicitly only wants them being private.

Imo this is the only way to go as a user usually doesn't see/check what 
bytecode really got generated for him.

Any objections?


LieGrue,
strub


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

Re: svn commit: r1424618 - in /commons/sandbox/privilizer/trunk: ./ ant/ ant/lib/ ant/test/ example/ maven-plugin/ modules/ modules/privilizer/ modules/privilizer/api/ modules/privilizer/api/src/main/

[Mark Struberg]

Jörg, what about all older living projects which used to have own groups even, 
like commons-lang:commons-lang?

Could you point me to this boilerplate stuff you think off? Maybe we can 
improve this.

I have no problem with moving the packages back, but I personally think this 
would á la long end up in confusing end users.

LieGrue,
strub




- Original Message -
 From: Jörg Schaible joerg.schai...@gmx.de
 To: dev@commons.apache.org
 Cc: 
 Sent: Friday, December 21, 2012 1:23 AM
 Subject: Re: svn commit: r1424618 - in /commons/sandbox/privilizer/trunk: ./ 
 ant/ ant/lib/ ant/test/ example/ maven-plugin/ modules/ modules/privilizer/ 
 modules/privilizer/api/ 
 modules/privilizer/api/src/main/java/org/apache/commons/weaver/privilizer/ 
 modules/privi...
 
 Matt Benson wrote:
 
  Mark,
    Thanks for driving this forward--as I mentioned to you privately, 
 I'll
    be
  mostly out of pocket through the new year.  The groupId may warrant
  discussion; most Commons components are being targeted to
  org.apache.commons, though I think I understand what you're driving at
  here:  [weaver] may have some unlimited number of sub(-sub*)-modules which
  may warrant oac.weaver as a groupId.
 
 Actually I think this is a bad idea. We manage all of our components as one 
 large group and should not break consistency here. I don't want to know what 
 
 effect this also has on some of our boiler plates we use for the build.
 
 - Jörg
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org


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

Re: svn commit: r1424618 - in /commons/sandbox/privilizer/trunk: ./ ant/ ant/lib/ ant/test/ example/ maven-plugin/ modules/ modules/privilizer/ modules/privilizer/api/ modules/privilizer/api/src/main/

[Mark Struberg]

No worries Jörg, I was just not aware of those additional steps/scripts.
From a pure maven perspective I would prefer separate groupIds but I get your 
arguments regarding the other tooling.

Thanks for pointing me to this background!

I will change the groupIds back to o.a.c.

LieGrue,
strub



- Original Message -
 From: Jörg Schaible joerg.schai...@scalaris.com
 To: dev@commons.apache.org
 Cc: 
 Sent: Friday, December 21, 2012 10:31 AM
 Subject: Re: svn commit: r1424618 - in /commons/sandbox/privilizer/trunk: ./ 
 ant/ ant/lib/ ant/test/ example/ maven-plugin/ modules/ modules/privilizer/ 
 modules/privilizer/api/ 
 modules/privilizer/api/src/main/java/org/apache/commons/weaver/privilizer/ 
 modules/privi...
 
 Hi Mark,
 
 Mark Struberg wrote:
 
  Jörg, what about all older living projects which used to have own groups
  even, like commons-lang:commons-lang?
 
 groupIds with pattern commons-XXX are legacy and we keep them only because 
 the relocation stuff of Maven does not really work well and we don't want to 
 
 harass our users as long as any newer release is binary compatible. However, 
 for new components or as soon as a new binary incompatible version of an old 
 one is to be released, we change the groupId always to org.commons.apache 
 and this had been the case for *all* components until now.
 
  Could you point me to this boilerplate stuff you think off? Maybe we can
  improve this.
 
 IIRC we derive the value for the groupId from our parent pom at various 
 places and we had also manual tasks for infra for all our components with a 
 groupId of commons-xxx and I am not sure if this applies to all groupIds 
 that are unequal to org.apache.commons.
 
  I have no problem with moving the packages back, but I personally think
  this would á la long end up in confusing end users.
 
 As said, we have with vfs2 and jci already other commons components that 
 make a precedence for multiple artifacts of one component. We share 
 org.apache.commons as common groupId and therefore I am against a silent 
 change of naming policy here. Note, that I did not veto the commit, because 
 I want to hear other opinions, but without a consensus among us committers, 
 I'd veto any such release.
 
 Cheers,
 Jörg
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org


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

Re: svn commit: r1424618 - in /commons/sandbox/privilizer/trunk: ./ ant/ ant/lib/ ant/test/ example/ maven-plugin/ modules/ modules/privilizer/ modules/privilizer/api/ modules/privilizer/api/src/main/

[Mark Struberg]

committed in r1424835.

Please note that weaver alone has 11 modules so far. And it's likely to become 
more...

LieGrue,
strub



- Original Message -
 From: Mark Struberg strub...@yahoo.de
 To: Commons Developers List dev@commons.apache.org
 Cc: 
 Sent: Friday, December 21, 2012 10:43 AM
 Subject: Re: svn commit: r1424618 - in /commons/sandbox/privilizer/trunk: ./ 
 ant/ ant/lib/ ant/test/ example/ maven-plugin/ modules/ modules/privilizer/ 
 modules/privilizer/api/ 
 modules/privilizer/api/src/main/java/org/apache/commons/weaver/privilizer/ 
 modules/privi...
 
 No worries Jörg, I was just not aware of those additional steps/scripts.
 From a pure maven perspective I would prefer separate groupIds but I get your 
 arguments regarding the other tooling.
 
 Thanks for pointing me to this background!
 
 I will change the groupIds back to o.a.c.
 
 LieGrue,
 strub
 
 
 
 - Original Message -
  From: Jörg Schaible joerg.schai...@scalaris.com
  To: dev@commons.apache.org
  Cc: 
  Sent: Friday, December 21, 2012 10:31 AM
  Subject: Re: svn commit: r1424618 - in /commons/sandbox/privilizer/trunk: 
 ./ ant/ ant/lib/ ant/test/ example/ maven-plugin/ modules/ 
 modules/privilizer/ 
 modules/privilizer/api/ 
 modules/privilizer/api/src/main/java/org/apache/commons/weaver/privilizer/ 
 modules/privi...
 
  Hi Mark,
 
  Mark Struberg wrote:
 
   Jörg, what about all older living projects which used to have own 
 groups
   even, like commons-lang:commons-lang?
 
  groupIds with pattern commons-XXX are legacy and we keep them only because 
  the relocation stuff of Maven does not really work well and we don't 
 want to 
 
  harass our users as long as any newer release is binary compatible. 
 However, 
  for new components or as soon as a new binary incompatible version of an 
 old 
  one is to be released, we change the groupId always to org.commons.apache 
  and this had been the case for *all* components until now.
 
   Could you point me to this boilerplate stuff you think off? Maybe we 
 can
   improve this.
 
  IIRC we derive the value for the groupId from our parent pom at various 
  places and we had also manual tasks for infra for all our components with a 
 
  groupId of commons-xxx and I am not sure if this applies to all groupIds 
  that are unequal to org.apache.commons.
 
   I have no problem with moving the packages back, but I personally 
 think
   this would á la long end up in confusing end users.
 
  As said, we have with vfs2 and jci already other commons components that 
  make a precedence for multiple artifacts of one component. We share 
  org.apache.commons as common groupId and therefore I am against a silent 
  change of naming policy here. Note, that I did not veto the commit, because 
 
  I want to hear other opinions, but without a consensus among us committers, 
 
  I'd veto any such release.
 
  Cheers,
  Jörg
 
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
  For additional commands, e-mail: dev-h...@commons.apache.org
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org


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

Re: svn commit: r1424618 - in /commons/sandbox/privilizer/trunk: ./ ant/ ant/lib/ ant/test/ example/ maven-plugin/ modules/ modules/privilizer/ modules/privilizer/api/ modules/privilizer/api/src/main/

[Mark Struberg]

Hi!

Yes, I find it not very handsome to pollute the o.a.commons directory itself 
with tons of modules which are completely unrelated to each other. That is fine 
with a single module project but imo definitely not ok for a project which 
consists of a few sub-modules.

Thus I'd rather collect all those (6++ modules) in o.a.commons.weaver/... 


LieGrue,
strub



- Original Message -
 From: Matt Benson gudnabr...@gmail.com
 To: dev@commons.apache.org
 Cc: 
 Sent: Thursday, December 20, 2012 10:20 PM
 Subject: Re: svn commit: r1424618 - in /commons/sandbox/privilizer/trunk: ./ 
 ant/ ant/lib/ ant/test/ example/ maven-plugin/ modules/ modules/privilizer/ 
 modules/privilizer/api/ 
 modules/privilizer/api/src/main/java/org/apache/commons/weaver/privilizer/ 
 modules/privi...
 
 Mark,
   Thanks for driving this forward--as I mentioned to you privately, I'll be
 mostly out of pocket through the new year.  The groupId may warrant
 discussion; most Commons components are being targeted to
 org.apache.commons, though I think I understand what you're driving at
 here:  [weaver] may have some unlimited number of sub(-sub*)-modules which
 may warrant oac.weaver as a groupId.
 
 Matt
 
 
 On Thu, Dec 20, 2012 at 12:33 PM, strub...@apache.org wrote:
 
  Author: struberg
  Date: Thu Dec 20 18:33:37 2012
  New Revision: 1424618
 
  URL: http://svn.apache.org/viewvc?rev=1424618view=rev
  Log:
  continue moving the privilizer to being a 'Weaver'
 
  Added:
 
 
 commons/sandbox/privilizer/trunk/modules/privilizer/weaver/src/main/java/org/apache/commons/weaver/privilizer/PrivilizerWeaver.java
    (with props)
 
 
 commons/sandbox/privilizer/trunk/modules/privilizer/weaver/src/main/resources/
 
 
 commons/sandbox/privilizer/trunk/modules/privilizer/weaver/src/main/resources/META-INF/
 
 
 commons/sandbox/privilizer/trunk/modules/privilizer/weaver/src/main/resources/META-INF/services/
 
 
 commons/sandbox/privilizer/trunk/modules/privilizer/weaver/src/main/resources/META-INF/services/org.apache.commons.weaver.spi.Weaver
  Modified:
      commons/sandbox/privilizer/trunk/ant/lib/pom.xml
      commons/sandbox/privilizer/trunk/ant/pom.xml
      commons/sandbox/privilizer/trunk/ant/test/pom.xml
      commons/sandbox/privilizer/trunk/example/pom.xml
      commons/sandbox/privilizer/trunk/maven-plugin/pom.xml
      commons/sandbox/privilizer/trunk/modules/pom.xml
      commons/sandbox/privilizer/trunk/modules/privilizer/api/pom.xml
 
 
 commons/sandbox/privilizer/trunk/modules/privilizer/api/src/main/java/org/apache/commons/weaver/privilizer/Privileged.java
      commons/sandbox/privilizer/trunk/modules/privilizer/pom.xml
      commons/sandbox/privilizer/trunk/modules/privilizer/weaver/pom.xml
      commons/sandbox/privilizer/trunk/pom.xml
      commons/sandbox/privilizer/trunk/processor/pom.xml
 
 
 commons/sandbox/privilizer/trunk/processor/src/main/java/org/apache/commons/weaver/WeaveProcessor.java
 
 
 commons/sandbox/privilizer/trunk/processor/src/main/java/org/apache/commons/weaver/spi/Weaver.java
 
 
 commons/sandbox/privilizer/trunk/processor/src/test/java/org/apache/commons/weaver/test/WeaveProcessorTest.java
 
 
 commons/sandbox/privilizer/trunk/processor/src/test/java/org/apache/commons/weaver/test/weaver/TestWeaver.java
 
  Modified: commons/sandbox/privilizer/trunk/ant/lib/pom.xml
  URL:
 
 http://svn.apache.org/viewvc/commons/sandbox/privilizer/trunk/ant/lib/pom.xml?rev=1424618r1=1424617r2=1424618view=diff
 
 
 ==
  --- commons/sandbox/privilizer/trunk/ant/lib/pom.xml (original)
  +++ commons/sandbox/privilizer/trunk/ant/lib/pom.xml Thu Dec 20 18:33:37
  2012
  @@ -20,7 +20,7 @@
     xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
     modelVersion4.0.0/modelVersion
     parent
  -    groupIdorg.apache.commons/groupId
  +    groupIdorg.apache.commons.weaver/groupId
       artifactIdcommons-weaver-antlib-parent/artifactId
       version0.1-SNAPSHOT/version
     /parent
  @@ -35,7 +35,7 @@
     /properties
     dependencies
       dependency
  -      groupIdorg.apache.commons/groupId
  +      groupIdorg.apache.commons.weaver/groupId
         artifactIdcommons-weaver-processor/artifactId
         version${project.version}/version
       /dependency
 
  Modified: commons/sandbox/privilizer/trunk/ant/pom.xml
  URL:
 
 http://svn.apache.org/viewvc/commons/sandbox/privilizer/trunk/ant/pom.xml?rev=1424618r1=1424617r2=1424618view=diff
 
 
 ==
  --- commons/sandbox/privilizer/trunk/ant/pom.xml (original)
  +++ commons/sandbox/privilizer/trunk/ant/pom.xml Thu Dec 20 18:33:37 2012
  @@ -18,7 +18,7 @@
    --project xmlns=http://maven.apache.org/POM/4.0.0; 
 xmlns:xsi=
  http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=
  http://maven.apache.org/POM/4.0.0
  http://maven.apache.org/xsd/maven-4.0.0.xsd;
     modelVersion4.0.0/modelVersion
     parent
  -    

Re: [VOTE][CANCEL] Release of commons-email-1.3 based on RC4

[Mark Struberg]

we had this over here at UPC as well. This did cost Sigi a release as well if 
you remember ;)

Most times this can be disabled by your provider. Just phone them and explain 
that they are breaking your computer and this creates costs by them not acting 
standard conform ;)


LieGrue,
strub



- Original Message -
 From: sebb seb...@gmail.com
 To: Commons Developers List dev@commons.apache.org
 Cc: 
 Sent: Tuesday, December 11, 2012 9:18 PM
 Subject: Re: [VOTE][CANCEL] Release of commons-email-1.3 based on RC4
 
 On 11 December 2012 12:11, Gary Gregory garydgreg...@gmail.com wrote:
  On Tue, Dec 11, 2012 at 6:56 AM, sebb seb...@gmail.com wrote:
 
  On 11 December 2012 08:58, Thomas Neidhart 
 thomas.neidh...@gmail.com
  wrote:
   Hi,
  
   thanks for looking into it.
  
   I will fix the issues wrt build page, release notes and findbugs
  warnings.
  
   Regarding the unit test failure:
  
   I have not seen the problem before, and just validated it. The 
 unit test
   tries to open a connection to an invalid url: 
 http://example.invalid
   For some reason this seems to succeed in your environment. Could 
 it be
  that
   you have a custom hosts entry for this domain?
 
  Or it could be a faulty DNS server.
 
  I used to have this exact problem with the OpenDNS server.
  They resolve unknown hosts to their home page (extra advertising).
  They used to do this for *.invalid as well, but after years of
  complaints that this behaviour was contrary to the RFC they fixed the
  issue.
 
  Try pinging example.invalid and then do an nslookup on the IP address.
 
 
  That is what Cox must be doing indeed:
 
  Pinging example.invalid [72.215.225.9] with 32 bytes of data:
  Request timed out.
  Request timed out.
  Request timed out.
  My browser redirects this IP to http://finder.cox.net/dnserror.html
 
 So Cox are violating the RFC.
 
 Perhaps you could direct them to the relevant RFC:
 
 There are several TLD names which are reserved by RFC 2606, section 2.
 Amongst them is the TLD invalid.
 
 quote
    .invalid is intended for use in online construction of domain
       names that are sure to be invalid and which it is obvious at a
       glance are invalid.
 /quote
 
 Note the phrase that are sure to be invalid.
 An invalid domain name cannot have an IP address.
 No DNS server should ever resolve addresses in the TLD invalid.
 
  Gary
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org


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

Re: [weaver]/[bcel] WAS [privilizer] promotion plan

[Mark Struberg]

One of the stuff I heard way back was that BCEL still has no native Java7 
support. 
Is this still true? Imo that was one of the reasons why openjpa went for doing 
parts of the bytecode stuff with ASM...

Happy to get proved wrong ;)

LieGrue,
strub




- Original Message -
 From: Matt Benson gudnabr...@gmail.com
 To: Commons Developers List dev@commons.apache.org
 Cc: 
 Sent: Wednesday, December 5, 2012 4:48 PM
 Subject: Re: [weaver]/[bcel] WAS [privilizer] promotion plan
 
 A [weaver] component as I envisioning it would provide e.g. a
 BytecodeWeaver interface, a custom implementation of which could be
 specified via:
 
 - the Maven plugin
 - the Antlib
 - the Java API
 
 Thus IMO it would be quite natural for [nabla] to make use of [weaver].
 
 From Torsten's/Mark's/Stephen's comments it sounds like using ASM 
 might be
 less painful after all, dog food be damned.  :/
 
 @Emmanuel:  My approach with the Antlib was to create a shaded uberjar so
 that the user wouldn't have to worry about dependencies.  This came out to
 900K, but typically this would be added to Ant's classpath rather than
 shipped per-project.  The API jar is 3K, and would be the only thing
 required for compilation.  Scale that by N weaver implementations (some of
 which possibly won't use a custom, or any, annotation) and the size of
 compilation dependencies would seem easily manageable.  Agreed?
 
 Matt
 
 
 On Wed, Dec 5, 2012 at 4:16 AM, Luc Maisonobe luc.maison...@free.fr 
 wrote:
 
  Hi all,
 
  Le 04/12/2012 23:54, Matt Benson a écrit :
   Well, it looks like the most comfortable avenue for everyone is 
 Commons
   [weaver].  IMO [weaver] would look like a framework for implementing 
 any
   kind of code weaving, so the most important decision is the look of 
 the
   API, and it would seem that eating our own dog food would be 
 appropriate
  in
   Commons.  Thus I would propose that [weaver] be built on top of 
 [BCEL],
  and
   I would think it likely that we might provide a nice (fluent?) API for
   common code modifications.
  
   Firstly, does anyone object to using [BCEL] as [weaver]'s 
 foundation?;
   secondly, can anyone tell me what (Java 7?) features [BCEL] currently
   lacks?; thirdly, does any of us already have the expertise to add 
 these?
 
  The [nabla] project also needs bytecode engineering. I don't know if it
  would fit within [weaver] API as it is really specific. It creates
  completely new classes using exisitng classes as templates, and the new
  classes generated methods contain deep modifications of the original
  methods (data flow analysis, types change, signatures changed, binding
  between generated and original methods and fields ...). Long ago, when
  [nabla] was only a personal project not yet contributed to commons, I
  used [BCEL] as the underlying bytecode engineering library. I finally
  switched to ASM as the [BCEL] API  was not sufficient for some of my
  needs, whereas ASM was a perfect fit.
 
  Once again, I'm not sure if [nabla] could benefit from [weaver], so 
 this
  comment may not be relevant in the discussion.
 
  best regards,
  Luc
 
  
   Thanks,
   Matt
  
  
   On Fri, Nov 30, 2012 at 6:35 AM, Emmanuel Bourg 
 ebo...@apache.org
  wrote:
  
   Le 29/11/2012 19:12, Matt Benson a écrit :
   This would go back to the idea of something like a BCEL 
 library
   (notwithstanding the fact that the existing privilizer code 
 does not
  use
   BCEL).
  
   For such a component BCEL would be an implementation detail, so I 
 don't
   think it should be a sub part of BCEL.
  
   If an annotation equivalent to @SwingInvokeLater can be added to 
 the
   project I would be highly interested in using it.
  
   As for the name of the component, what about Commons Weaver ?
  
   Emmanuel Bourg
  
  
  
  
 
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
  For additional commands, e-mail: dev-h...@commons.apache.org
 
 


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

Re: [privilizer] promotion plan

[Mark Struberg]

+1

It might fit to any component which does _not_ introduce a runtime dependency 
but is only needed at compile time. Basically the privilizer is kind of a 
preprocessor.

If such a kind of component already exists in commons, then we can look if it 
fits to the business of this component. Otherwise it's a new module imo.

LieGrue,
strub




- Original Message -
 From: Matt Benson gudnabr...@gmail.com
 To: Gary Gregory garydgreg...@gmail.com
 Cc: Commons Developers List dev@commons.apache.org
 Sent: Wednesday, November 28, 2012 10:08 PM
 Subject: Re: [privilizer] promotion plan
 
 Hi Gary,
   Feel free to suggest one or more alternate names, and we can vote on
 them!  The intent is to quickly convey that the component equips your code
 to run in a Java security constrained environment, thus 
 privilizer or
 that which makes your code privileged.  Since the main use of the
 component is to instrument compiled code during the build process (a
 possible future enhancement is to support RT enhancement in a custom
 classloader), I don't see that it fits into any existing component, but am
 open to correction.
 
 Thanks for your interest,
 Matt
 
 
 On Wed, Nov 28, 2012 at 2:55 PM, Gary Gregory 
 garydgreg...@gmail.comwrote:
 
  Another aspect to consider is would this new privalizer 
 component (not
  crazy about the name ATM) fit in an existing Commons component?
 
 
  On Wed, Nov 28, 2012 at 3:44 PM, Matt Benson gudnabr...@gmail.com 
 wrote:
 
  Hi all,
    As long as I've been part of the Commons community I don't 
 know that
  I've
  encountered this exact situation:  a committer adds some code to the
  sandbox that is more or less complete.  I don't know precisely what
  requirements must be met before we promote [privilizer] to proper. We 
 seem
  to have interest from one or more members of the PMC as prospective 
 users;
  this would seem to imply that were I hit by a bus there ought to be
  someone
  interested in maintaining the component.  Speaking for BVal I intend to
  put
  this component to immediate use there (that's what I wrote it 
 for!).  Mark
  has mentioned that OWB and perhaps other ASF projects might want to 
 make
  use of it.  What else do I need to do?
 
  Matt
 
 
 
 
  --
  E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
  JUnit in Action, 2nd Ed: http://goog_1249600977http://bit.ly/ECvg0
  Spring Batch in Action: http://s.apache.org/HOqhttp://bit.ly/bqpbCK
  Blog: http://garygregory.wordpress.com
  Home: http://garygregory.com/
  Tweet! http://twitter.com/GaryGregory
 


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

Re: [privilizer] new sandbox component

[Mark Struberg]

Oki, let me explain what I meant.
Currently the methods must be private to be really secure. But having a public 
method is not a problem if it does NOT contain any doPrivileged but if this 
wrapper is generated as private method of the caller. So people will 


As example please consider the following method in a SecurityUtils helper class:

public static ClassLoader getCurrentClassLoader(Class referencePoint) { .. }


and in another class you will have a single lined method

@Privileged
private ClassLoader getCurrentClassLoader(Class refPoint) {
  return SecurityUtils.getCurrentClassLoader(refPoint);
}


If someone calls the SecurityUtil method directly from outside (and does not 
use the commons-privilizer in his project or manualy wraps it with 
doPrivileged), then this method will throw a SecurityException as the 
SecurityManager will not allow this call.


What I was proposing is to generate the private helper method in the caller 
class for the user automatically. We could e.g. do this by introducing a 2nd 
annotation, e.g. @LocalPrivileged.

Writing 

@LocalPrivileged

public static ClassLoader getCurrentClassLoader(Class referencePoint) { .. }


and using the commons-privilizer in the project could do that. That's of course 
more work to do than the current approach, but could be worth looking at. That 
could be done in a v2 release as well.

LieGrue,
strub




 From: Matt Benson gudnabr...@gmail.com
To: Commons Developers List dev@commons.apache.org; Mark Struberg 
strub...@yahoo.de 
Sent: Tuesday, November 20, 2012 5:31 PM
Subject: Re: [privilizer] new sandbox component
 






On Tue, Nov 20, 2012 at 10:12 AM, Mark Struberg strub...@yahoo.de wrote:

Heh, the other option has been 'privilator'

Catchy as well, and would have given a nice slogan: 'Privilator - I'll be 
secure, baby'

It's a bit less self-explaining though.


We are looking forward to use it in Apache BVal, OpenWebBeans, DeltaSpike and 
probably MyFaces for now.

One thing I like to give a try is to generate private method wrappers in all 
_caller_ classes. That would even allow for public helper methods which are 
perfectly save.



This is a point on which Mark and I differ, so if this is implemented I prefer 
to do it as an option, perhaps using a different annotation, e.g. 
@RequiresPrivileges.  My concern is that there could be any number of callers, 
so the task of finding and weaving them all is a large one (I wouldn't even 
know what existing libraries will perform for me a search for all callers of 
method Foo#bar(), and what about reflection-based invocations?), and it means 
you can't simply distribute a library and call it privilized.  :)  Of 
course, none of this is anything you can't do with e.g. AspectJ, but as 
mentioned in the overview the [privilizer] code adds no runtime dependencies 
(not even its own API jar!).

Matt
 
LieGrue,
strub



- Original Message -
 From: Matt Benson gudnabr...@gmail.com
 To: Commons Developers List dev@commons.apache.org
 Cc:
 Sent: Tuesday, November 20, 2012 6:40 AM
 Subject: Re: [privilizer] new sandbox component

G lad to hear it, Phil!  I was originally calling it privileged method

 weaver but that's a little long for a Commons component.  Mark
 Struberg
 came up with privilizer for me--short, but still fairly suggestive
 of the
 component's purpose.

 Matt


 On Mon, Nov 19, 2012 at 8:04 PM, Phil Steitz phil.ste...@gmail.com
 wrote:

  On 11/19/12 2:42 PM, Matt Benson wrote:
   Hi all,
     I have recently been working on some code to simplify the task of
  working
   with the Java security APIs and an ASF colleague convinced me that the
   package had a chance of being a viable Commons component.  I have
 added
  it
   to the sandbox and it is available on the website by now as well.
   Typically code that is too done doesn't fare too well
 at the ASF in
   general; one obvious improvement that might be made would be the
   replacement of Javassist with ASM or perhaps BCEL, but the existing
   implementation represented a path of least resistance for me.  Anyway,
  I'd
   be glad for any feedback, questions, or tomatoes.
  
   Thanks,
   Matt
  
  Sweet!  I recently had need for exactly this.  Lets argue about the
  name - or not ;)  I love it!

  Phil

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




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






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

Re: [privilizer] new sandbox component

[Mark Struberg]

Well, anyone can invoke such a method in it's own code. The point is where the 
doPrivileged block is opened.


If a method is annotated with this newly proposed @LocalPrivileged then this 
method itself would NOT get wrapped with doPrivileged. But instead a private 
method with a doPrivileged block will get added to the callers class and the 
invocation will get replaced with that method. 


Maybe I miss something, but for me that sounds safe.

LieGrue,
strub






 From: Matt Benson gudnabr...@gmail.com
To: Commons Developers List dev@commons.apache.org; Mark Struberg 
strub...@yahoo.de 
Sent: Wednesday, November 21, 2012 4:22 PM
Subject: Re: [privilizer] new sandbox component
 






On Wed, Nov 21, 2012 at 4:57 AM, Mark Struberg strub...@yahoo.de wrote:

Oki, let me explain what I meant.
Currently the methods must be private to be really secure. But having a 
public method is not a problem if it does NOT contain any doPrivileged but if 
this wrapper is generated as private method of the caller. So people will


As example please consider the following method in a SecurityUtils helper 
class:

public static ClassLoader getCurrentClassLoader(Class referencePoint) { .. }


and in another class you will have a single lined method

@Privileged
private ClassLoader getCurrentClassLoader(Class refPoint) {
  return SecurityUtils.getCurrentClassLoader(refPoint);
}


If someone calls the SecurityUtil method directly from outside (and does not 
use the commons-privilizer in his project or manualy wraps it with 
doPrivileged), then this method will throw a SecurityException as the 
SecurityManager will not allow this call.


What I was proposing is to generate the private helper method in the caller 
class for the user automatically. We could e.g. do this by introducing a 2nd 
annotation, e.g. @LocalPrivileged.

Writing 

@LocalPrivileged

public static ClassLoader getCurrentClassLoader(Class referencePoint) { .. }


and using the commons-privilizer in the project could do that. That's of 
course more work to do than the current approach, but could be worth looking 
at. That could be done in a v2 release as well.



The problem with this is that the privileged APIs work such that SecurityUtils 
would still have to have full privileges; i.e., the PrivilegedAction call only 
insulates backward in the call stack, not forward.  It took me ages to get my 
head around that, and ages more once I had stepped away for a couple of 
months.  If SecurityUtils still has privileges graned, anyone can call its 
methods and we're back to square one.

Glad to be proven wrong...

Matt
 
LieGrue,
strub




 From: Matt Benson gudnabr...@gmail.com
To: Commons Developers List dev@commons.apache.org; Mark Struberg 
strub...@yahoo.de
Sent: Tuesday, November 20, 2012 5:31 PM

Subject: Re: [privilizer] new sandbox component







On Tue, Nov 20, 2012 at 10:12 AM, Mark Struberg strub...@yahoo.de wrote:

Heh, the other option has been 'privilator'

Catchy as well, and would have given a nice slogan: 'Privilator - I'll be 
secure, baby'

It's a bit less self-explaining though.


We are looking forward to use it in Apache BVal, OpenWebBeans, DeltaSpike 
and probably MyFaces for now.

One thing I like to give a try is to generate private method wrappers in 
all _caller_ classes. That would even allow for public helper methods which 
are perfectly save.



This is a point on which Mark and I differ, so if this is implemented I 
prefer to do it as an option, perhaps using a different annotation, e.g. 
@RequiresPrivileges.  My concern is that there could be any number of 
callers, so the task of finding and weaving them all is a large one (I 
wouldn't even know what existing libraries will perform for me a search for 
all callers of method Foo#bar(), and what about reflection-based 
invocations?), and it means you can't simply distribute a library and call 
it privilized.  :)  Of course, none of this is anything you can't do with 
e.g. AspectJ, but as mentioned in the overview the [privilizer] code adds no 
runtime dependencies (not even its own API jar!).

Matt
 
LieGrue,
strub



- Original Message -
 From: Matt Benson gudnabr...@gmail.com
 To: Commons Developers List dev@commons.apache.org
 Cc:
 Sent: Tuesday, November 20, 2012 6:40 AM
 Subject: Re: [privilizer] new sandbox component

G lad to hear it, Phil!  I was originally calling it privileged method

 weaver but that's a little long for a Commons component.  Mark
 Struberg
 came up with privilizer for me--short, but still fairly suggestive
 of the
 component's purpose.

 Matt


 On Mon, Nov 19, 2012 at 8:04 PM, Phil Steitz phil.ste...@gmail.com
 wrote:

  On 11/19/12 2:42 PM, Matt Benson wrote:
   Hi all,
     I have recently been working on some code to simplify the task of
  working
   with the Java security APIs and an ASF colleague convinced me that the
   package had a chance of being a viable Commons component

Re: [privilizer] new sandbox component

[Mark Struberg]

Heh, the other option has been 'privilator'

Catchy as well, and would have given a nice slogan: 'Privilator - I'll be 
secure, baby'

It's a bit less self-explaining though.


We are looking forward to use it in Apache BVal, OpenWebBeans, DeltaSpike and 
probably MyFaces for now.

One thing I like to give a try is to generate private method wrappers in all 
_caller_ classes. That would even allow for public helper methods which are 
perfectly save.

LieGrue,
strub



- Original Message -
 From: Matt Benson gudnabr...@gmail.com
 To: Commons Developers List dev@commons.apache.org
 Cc: 
 Sent: Tuesday, November 20, 2012 6:40 AM
 Subject: Re: [privilizer] new sandbox component
 
G lad to hear it, Phil!  I was originally calling it privileged method
 weaver but that's a little long for a Commons component.  Mark 
 Struberg
 came up with privilizer for me--short, but still fairly suggestive 
 of the
 component's purpose.
 
 Matt
 
 
 On Mon, Nov 19, 2012 at 8:04 PM, Phil Steitz phil.ste...@gmail.com 
 wrote:
 
  On 11/19/12 2:42 PM, Matt Benson wrote:
   Hi all,
     I have recently been working on some code to simplify the task of
  working
   with the Java security APIs and an ASF colleague convinced me that the
   package had a chance of being a viable Commons component.  I have 
 added
  it
   to the sandbox and it is available on the website by now as well.
   Typically code that is too done doesn't fare too well 
 at the ASF in
   general; one obvious improvement that might be made would be the
   replacement of Javassist with ASM or perhaps BCEL, but the existing
   implementation represented a path of least resistance for me.  Anyway,
  I'd
   be glad for any feedback, questions, or tomatoes.
  
   Thanks,
   Matt
  
  Sweet!  I recently had need for exactly this.  Lets argue about the
  name - or not ;)  I love it!
 
  Phil
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
  For additional commands, e-mail: dev-h...@commons.apache.org
 
 


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

Re: Proposal Commons-JNDI

[Mark Struberg]

+1, such a thingy is needed pretty often!

LieGrue,
strub



- Original Message -
 From: Phil Steitz phil.ste...@gmail.com
 To: Commons Developers List dev@commons.apache.org
 Cc: 
 Sent: Wednesday, August 8, 2012 4:50 PM
 Subject: Re: Proposal Commons-JNDI
 
 On 8/7/12 11:02 PM, Jochen Wiedmann wrote:
  Hi,
 
  I'd like to propose a new component Commons JNDI for the sandbox.
 
  The aim would be to have a very lightweight JNDI implementation (no
  server, or something like that) that's not necessarily suitable for
  production, but ideally suited for use in test suites, and the like.
  For example, commons dbcp might use this to verify configuration via
  JNDI. The new implementation ought to be driven by property, XML, or
  JSON files.
  Possible starting points:
 
  - Import Simple JNDI, which already comes very close to the target.
  Henri Yandell, one of the Simple JNDI authors has given his agreement.
  - Import Tomcat JNDI, no contact with the Tomcat developers exists on
  that topic.
 
 +1 - Gary's DS suggestion also merits a look.  But do-ocracy rules -
 whichever them who is doin' the work likes the most should win.  We
 just need to make sure whatever we start with gets granted
 appropriately if it is not from scratch.  Years ago, we started
 such a thing here, based on the tomcat in-memory provider and then
 moved it to the then incubating ADS project.  It died there.  +1 to
 try again here.
 
 Phil
 
 
  WDYT?
 
  Jochen
 
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org


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

Re: another new URL() question

[Mark Struberg]

I grabbed a bit deeper and it's even more fup.

Some containers don't even add 'file://' to the externalForm() they return in 
their URLs. You have to add this yourself when doing new URL().
There is no way to have new URL() working properly in a generic way. We must go 
Davids route via an 'Archive' abstraction layer which we could plug-in.

LieGrue,
strub



- Original Message -
 From: Honton, Charles charles_hon...@intuit.com
 To: Commons Developers List dev@commons.apache.org; gudnabr...@gmail.com 
 gudnabr...@gmail.com; Mark Struberg strub...@yahoo.de
 Cc: 
 Sent: Monday, June 11, 2012 6:10 PM
 Subject: Re: another new URL() question
 
 Mark,
 
 The only mechanism available to extend URLClassLoader's protocol handling
 in a Sun jvm is to add a URLStreamHandler.  It's a difficult task to
 re-implement the class loading architecture, and I'm sure the application
 server environments don't mess with this basic.  (I'm not so sure about
 the Android vm)
 
 The URLStreamHandler is used by the URL class to parse the string
 representation into a URL object.  So I'm really surprised by the
 situation where !url.equals(new URL(url.toExternalForm())).
 
 You mentioned that wsjar:// failed this test.  Does websphere return this
 URL from a ClassLoader.getResource()?  If so, what is the class type of
 that instance? (Probably something written by websphere)
 
 We could add a URLStreamHandler to handle parsing (and handling stream
 requests for) the wsjar URL.
 
 Chas
 
 
 On 6/11/12 7:23 AM, Matt Benson gudnabr...@gmail.com wrote:
 
 Hi, Mark!  This is why I was confused when we touched on this on
 IRC--I was thinking that the correct handling of URLs was an
 orthogonal function to [classscan]'s *use* of those same URLs, for
 this reason.  I had thought there had been, at one time, an OSS Java
 project to help manage these URLStreamHandlers, but I haven't had any
 luck finding it again.  If we never do, this could be a second sandbox
 component, a new piece for Commons [io], or...?  It could be an
 interesting setup to have a core management infrastructure, with any
 number of pluggable modules for different OS/container/et al
 platforms?
 
 Matt
 
 On Mon, Jun 11, 2012 at 1:56 AM, Mark Struberg strub...@yahoo.de 
 wrote:
  Regarding the new URL() problem some of you might have more experience
 than I do. I only know the problems on some platforms, and after looking
 at the URL class in detail, I really wonder whether that was me doing it
 wrong or a platform bug.
 
  My understanding problem is mainly around the URLStreamHandler. There
 is a method where one can set a URLStreamHandlerFactory (once for JVM
 lifetime):
 
  URL#setURLStreamHandlerFactory(URLStreamHandlerFactory fac)
 
  Thus when a ClassLoader#getResources() returns an URL with 
 wsjar://
 as protocol and it cannot be used for new URL(), then can I safely
 assume this is a problem in the container setup? This happens on Oracles
 own WebLogic...
 
  I have not yet tried the following way:
 
  String protocol = wsjar;
  URLStreamHandler getURLStreamHandler(protocol)
 
  and then use the following URL constructor:
 
  public URL(URL context, String spec, URLStreamHandler handler)
 
 
  Can anyone test if this works? Or does anyone know already?
  We might hack a small JSP page which scans for META-INF/MANIFEST.MF and
 reports errors with new URL(). That way we could spread the test onto
 various platforms.
 
  LieGrue,
  strub
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
  For additional commands, e-mail: dev-h...@commons.apache.org
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org
 
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org


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

another new URL() question

[Mark Struberg]

Regarding the new URL() problem some of you might have more experience than I 
do. I only know the problems on some platforms, and after looking at the URL 
class in detail, I really wonder whether that was me doing it wrong or a 
platform bug.

My understanding problem is mainly around the URLStreamHandler. There is a 
method where one can set a URLStreamHandlerFactory (once for JVM lifetime):

URL#setURLStreamHandlerFactory(URLStreamHandlerFactory fac)

Thus when a ClassLoader#getResources() returns an URL with wsjar:// as 
protocol and it cannot be used for new URL(), then can I safely assume this is 
a problem in the container setup? This happens on Oracles own WebLogic...

I have not yet tried the following way:

String protocol = wsjar;
URLStreamHandler getURLStreamHandler(protocol)

and then use the following URL constructor:

public URL(URL context, String spec, URLStreamHandler handler)


Can anyone test if this works? Or does anyone know already?
We might hack a small JSP page which scans for META-INF/MANIFEST.MF and reports 
errors with new URL(). That way we could spread the test onto various platforms.

LieGrue,
strub

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

Re: [classscan] new URL(xxx) and it's problems

[Mark Struberg]

no. and thats exactly the problem. 


LieGrue,
strub


- Original Message -
 From: Honton, Charles charles_hon...@intuit.com
 To: Mark Struberg strub...@yahoo.de; Commons Developers List 
 dev@commons.apache.org
 Cc: 
 Sent: Thursday, June 7, 2012 5:28 PM
 Subject: Re: [classscan] new URL(xxx) and it's problems
 
 
 In that environment, does new URL(wsjar:///...) succeed?
 
 
 
 On 6/6/12 9:22 PM, Mark Struberg strub...@yahoo.de wrote:
 
 Yes, we had this pretty commonly in OWB. You might get funny strings like
 wsjar:///... as URL.toExternalForm() :(
 Basically all Systems which do not use the native file system but an own
 virtual files system implementation for storing apps, like JBossAS,
 WebLogic, WebSphere, etc
 
 For storing URLs in a map you need to do special tricks :(
 
 
 LieGrue,
 strub
 
 
 
 - Original Message -
  From: Honton, Charles charles_hon...@intuit.com
  To: Commons Developers List dev@commons.apache.org; Mark 
 Struberg
 strub...@yahoo.de
  Cc: 
  Sent: Thursday, June 7, 2012 1:59 AM
  Subject: Re: [classscan] new URL(xxx) and it's problems
 
 
  I did originally use URLs.  Due to the ugliness Mark alludes to, I 
 moved
  to URIs.  The biggest performance consideration was using a URL as a 
 Key
  to a map.  That completely blew up performance.
 
  Does anyone have a concrete example of !url.equals(new
  URL(url.toExternalForm()) ?
 
  Thanks,
  Chas
 
 
  On 6/6/12 1:13 PM, Mark Struberg strub...@yahoo.de 
 wrote:
 
  Hi!
 
  I've now looked through both impls and both share some very 
 similar API
  classes obviously (MetaClass, MetaField, etc). Details are 
 different,
 but
  I think we can extract a common API.
 
  One thing I figured while looking at the code is that some parts 
 are
 full
  with URI handling instead of URL.
  The problem with this is that an URI#toURL() internally does a new
  URL(uri.toString());
 
 
  Now the problem hereby is that on some systems a
 
 
  URL u = someResource.getURL();
  URL u2 = new URL(u.toExternalForm());
 
  doesn't work. Those methods are just not reflexive on some 
 systems.
 
 
  This happens often if VFS are involved (e.g. on JBossAS4,5,6, 
 WebLogic,
  etc) and even in general on some OS (Solaris 10.5/Sparc).
 
 
  The only way I know to cope with it is to _not_ only store the 
 String
  representation but the URL itself. This sucks big times as well,
 because
  URL is a class which escaped from hell - doing DNS lookup on 
 equals()
 and
  other weird things *shudder* - but I don't know of any better 
 way :(
 
  Any tip is welcome.
 
  LieGrue,
  strub
 
 
 
 -
  To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
  For additional commands, e-mail: dev-h...@commons.apache.org
 
 
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org


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

Re: [classscan] Metadata API discussion

[Mark Struberg]

Hi folks, quick reply from vacation :)


@sebb: yes correct. I was just thinking too complicated. We use the interface 
only for keeping the metainfo, and not in the metainfo itself. So it should 
itself not blow up the mem. So +1 for the interface.

There are 2 important consideration options left:

a.) Store the information we get from BCEL/ASM directly in the meta-info 
instances.

b.) Take the information we get from BCEL/ASM and store them e.g. in a 
SingleLinkedList or array. 

Which one is more effective also has to do whether BCEL/ASM throw away their 
information after they pass it to us or if they keep it internally for later 
reuse. If they store the information anyway, then  a.) is better - otherwise we 
should do b.)



LieGrue,
strub


- Original Message -
 From: Honton, Charles charles_hon...@intuit.com
 To: Commons Developers List dev@commons.apache.org
 Cc: 
 Sent: Friday, June 8, 2012 5:47 PM
 Subject: Re: [classscan] Metadata API discussion
 
 In on my MacBook, I get the following counts for running just the unit
 tests:
 
 Java(TM) SE Runtime Environment (build 1.6.0_29-b11-402-10M3527)
 Java HotSpot(TM) 64-Bit Server VM (build 20.4-b02-402, mixed mode)
 
 Cache:    1
 BootstrapClassLoader:    1
 WeakConcurrentHashMap:    1
 MetaUrlClassLoader:    2
 HashWeakReference:    5
 FileClassLocation:    5
 PrimitiveClass:    9
 JarClassLocation:    27
 SortedReadOnlySet:    38
 BcelEnumProperty:    296
 BcelProperty:    740
 AnnotationMap$1:    3217
 BcelAnnotation:    3417
 BcelClass$1:    9251
 DeferredMetaClass:    13620
 BcelClass$3:    18232
 BcelClass$2:    26096
 BcelClass:    26774
 ArrayMetaType:    33275
 ReadOnlySet:    54240
 BcelField:    110983
 BcelMethod:    231549
 BcelParameter:    264572
 ClassMetaType:    607104
 AnnotationMap:    633878
 
 Regards,
 
 chas
 
 
 On 6/7/12 5:27 PM, James Carman jcar...@carmanconsulting.com 
 wrote:
 
 There can be quite a few if you have to have them for every class,
 interface, annotation, method, field, etc.  Then again if you just reuse 1
 adapter object all the time it wouldn't be that bad. You would just have
 to
 let users know that they cannot maintain references to those objects after
 scanning is complete.
 On Jun 7, 2012 8:10 PM, sebb seb...@gmail.com wrote:
 
  On 7 June 2012 21:11, James Carman ja...@carmanconsulting.com 
 wrote:
   On Thu, Jun 7, 2012 at 3:56 AM, sebb seb...@gmail.com 
 wrote:
  
   Not sure I follow this. Why would an interface use extra 
 memory?
   I can see that it might add a bit more to the static size of a 
 class,
   but why would it add more to each instance of a class that 
 uses it?
  
  
   It's not the interface itself.  It's the fact that you 
 have to have
   more objects loaded into memory when you use the interface-based
   approach.  For example, if BCEL has some object that represents a
   class' metadata, then we'll have to put some 
 adapter object in front
   of it that implements our metadata API interface and knows how to
   speak BCEL-speak to extract the information.
 
  Yes, but again, surely there won't be all that many such objects?
 
  I think some tests should be done of the two approaches before
  deciding to abandon the interface-based design.
 
   
 -
   To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
   For additional commands, e-mail: dev-h...@commons.apache.org
  
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
  For additional commands, e-mail: dev-h...@commons.apache.org
 
 
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org


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

Re: [ALL] Using a Tool Like Sonar...

[Mark Struberg]

we have an own Sonar installation at http://analysis.apache.org already.
You just need to tell infra that you like to have your project added.

LieGrue,
strub



- Original Message -
 From: Simone Tripodi simonetrip...@apache.org
 To: Commons Developers List dev@commons.apache.org
 Cc: 
 Sent: Saturday, June 9, 2012 8:09 AM
 Subject: Re: [ALL] Using a Tool Like Sonar...
 
 +1 we are using it also in Cocoon and helps a lot - IMHO it should
 replace public static reports generated and published by mvn...
 best,
 -Simo
 
 http://people.apache.org/~simonetripodi/
 http://simonetripodi.livejournal.com/
 http://twitter.com/simonetripodi
 http://www.99soft.org/
 
 
 On Sat, Jun 9, 2012 at 12:19 AM, James Carman
 ja...@carmanconsulting.com wrote:
  All,
 
  I've really become fond of Sonar (http://www.sonarsource.org/) in the
  past 6 months or so.  I install the Sonar plugin in Jenkins and turn
  on Sonar for my builds and I get Continuous Inspection of my 
 code
  which helps me find potential issues.  It uses tools like Findbugs,
  PMD, Checkstyle, etc. and aggregates the results into one easy-to-use
  interface.  What would you guys think about introducing something like
  that into Apache Commons to help us improve our code quality?
 
  Thanks,
 
  James
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
  For additional commands, e-mail: dev-h...@commons.apache.org
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org


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

Re: [classscan] Experiment on xbean-finder

[Mark Struberg]

Hi!

I now moved all the stuff to trunk.

Next I'll work on a structure for the API and extract a mainingful api from 
both Chas' and Davids 'backends' + do the initial maven setup stuff.

LieGrue,
strub



- Original Message -
 From: Mark Struberg strub...@yahoo.de
 To: Commons Developers List dev@commons.apache.org
 Cc: 
 Sent: Wednesday, June 6, 2012 7:50 AM
 Subject: Re: [classscan] Experiment on xbean-finder
 
g ood stuff.
 
 I'd like to go on and do the following:
 
 in ./trunk add the following new directories
 
 tck - our mass tests, etc which we can use for common testing, performance 
 measurements, etc
 
 api - the part a user interacts with
 impl-bcel - move Chas' work to
 impl-xbf - move branches/commons-finder to
 
 LieGrue,
 strub
 
 
 
 - Original Message -
  From: David Blevins david.blev...@gmail.com
  To: Commons Developers List dev@commons.apache.org; 
 gudnabr...@gmail.com
  Cc: 
  Sent: Wednesday, June 6, 2012 7:32 AM
  Subject: Re: [classscan] Experiment on xbean-finder
 
  An expanded view of the info below in markdown:
 
    https://gist.github.com/2880038
 
  Pulled in some also pulled in some Meta-Annotation information from the 
  proposals going around Java EE 7.  There's a lot there, feel free to 
 ignore 
  it.  Not critical.
 
 
  -David
 
 
  On Jun 5, 2012, at 9:57 PM, David Blevins wrote:
 
 
   On Jun 5, 2012, at 1:12 PM, Matt Benson wrote:
 
   Welcome, David!
 
   Thanks, Matt!
 
   Ok, so I refactored it a bit to work in some of the ideas I was 
 hearing on 
  IRC today.
 
   Those changes were primarily:
   - Promote Info objects that represent class data to a separate package 
 not 
  tied to any bytecode library
   - Add listener interface to consume the Info objects
   - Added parser abstraction to use ASM or similar library to create the 
 Info 
  objects and invoke listener
 
   The code was there and generally written somewhat decoupled with those 
 
  parts in mind.  Took a bit of snipping and cutting here and there to fully 
  decouple it and separate everything out into separate packages.
 
   There's no ParserFacory yet, that could easily be created.  I 
 figured 
  there was enough there to show how things work.
 
   Here's an overview of the code:
 
   org.apache.commons.classscan.finder
   - AnnotationFinder
   - IAnnotationFinder
   - ResourceFinder
 
   AnnotationFinder is essentially the db and has methods to 
  query.
 
   ResourceFinder is for basic file location such as 
  META-INF/persistence.xml and can also be used as part of a 
  ServiceLoader replacement.  See the ResourceFinder.mdtext for details
 
 
   org.apache.commons.classscan.finder.archive
   - Archive
   - ArchiveIterator
   - ClassesArchive
   - ClasspathArchive
   - CompositeArchive
   - FileArchive
   - FilteredArchive
   - JarArchive
 
   The Archive interface allows for sources of class files to be 
 abstracted.  
  The JarArchive, ClassesArchive and FileArchive are concrete 
 implementations.  
  CompositeArchive is simply a collection of Archive implementations.  
  FilteredArchive allows for the archive itself to be filtered in various 
 ways.
 
   org.apache.commons.classscan.finder.filter
   - ClassFilter
   - ContainsFilter
   - ExcludeIncludeFilter
   - Filter
   - FilterList
   - Filters
   - IncludeExcludeFilter
   - PackageFilter
   - PatternFilter
   - PrefixFilter
   - SuffixFilter
 
   The Filter interface simply allows you to give a yay or nay to a 
 String.  
  This is of course useful for greatly limiting the classes actually scanned 
 when 
  combined with an Archive via wrapping it with a FilteredArchive and 
 supplying a 
  Filter.
 
   FilterList is a Filter implementation that combines one or more 
 filters.  
  Both yes and no filters can be used via 
  IncludeExcludeFilter or ExcludeIncludeFilter which are modeled after HTTPd 
  allowed host pattern.
 
   PackageFilter, ClassFilter, SuffixFilter, PrefixFilter, ContainsFilter 
 and 
  PatternFilter are concrete implementations of Filter that each have a 
 simple 
  approach to testing the string to give a yay or nay.
 
   The Filters class is a convenience class that makes it easy to 
 construct 
  the various filters with little syntax as well as performs unwrapping when 
  necessary if it sees things like a FilterList with only one filter or a 
  FilterList containing another FilterList.
 
 
   org.apache.commons.classscan.finder.meta
   - Annotated
   - AnnotatedMember
   - AnnotatedMethod
   - MetaAnnotated
   - MetaAnnotatedClass
   - MetaAnnotatedConstructor
   - MetaAnnotatedElement
   - MetaAnnotatedField
   - MetaAnnotatedMethod
   - MetaAnnotation
 
   This package provides basic support for meta-annotations which are 
 simply 
  annotation reuse or inheritance.  CDI, Bean Validation and JAX-RS all have 
  similar concepts of inheritance.  This code does a more generic approach to 
 
  reuse that isn't tied to any one particular specification.  Fun to play

[classscan] java5 or java6 as lang level in commons nowadays?

[Mark Struberg]

Hi!

Should we set our java language level to java5 or java6?

LieGrue,
strub


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

[classscan] new URL(xxx) and it's problems

[Mark Struberg]

Hi!

I've now looked through both impls and both share some very similar API classes 
obviously (MetaClass, MetaField, etc). Details are different, but I think we 
can extract a common API.

One thing I figured while looking at the code is that some parts are full with 
URI handling instead of URL.
The problem with this is that an URI#toURL() internally does a new 
URL(uri.toString()); 


Now the problem hereby is that on some systems a 


URL u = someResource.getURL();
URL u2 = new URL(u.toExternalForm());

doesn't work. Those methods are just not reflexive on some systems. 


This happens often if VFS are involved (e.g. on JBossAS4,5,6, WebLogic, etc) 
and even in general on some OS (Solaris 10.5/Sparc). 


The only way I know to cope with it is to _not_ only store the String 
representation but the URL itself. This sucks big times as well, because URL is 
a class which escaped from hell - doing DNS lookup on equals() and other weird 
things *shudder* - but I don't know of any better way :(

Any tip is welcome.

LieGrue,
strub


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

[classscan] Metadata API discussion

[Mark Struberg]

Hi!

I now did read through the metadata classes of Chas' and Davids impls.

Both look pretty similar to some degree. A few key differences

* using AnnotatedElement instead of HasName() makes it possible to replace most 
'old' code which does getAnnotations() etc 1:1
 Imo we should keep this feature.

* to interface or not to interface, that's the question. 

 The actual meta information should be as small as possible. There are tons of 
it. 

 1. Currently in Chas' impl there are bcel specific parts in it. Can those 
probably be extracted? I think so, or do you see any problems? If we cannot 
split then we should keep the interfaces. But remember that this takes (a bit) 
more space in mem.
 2. If Interfaces, then impls could point to bcel/asm internal strutures for 
storing the data. This would reduce space. But only if bcel/asm would keep this 
info anyway. Otherswise it might be better to throw the bcel/asm stuff away 
after repackaging to a small meta info holder.



(just to not loose some questions... more to come...)

LieGrue,
strub

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