I guess that is a question for the JasperReports team.
Melloware
@melloware on GitHub
> On May 20, 2025, at 5:37 PM, Gary Gregory wrote:
>
> Creating a PR in JasperReports runs... zero tests?
>
> Gary
>
>
>> On Tue, May 20, 2025 at 4:41 PM Melloware Inc
>> wrote:
>>
>> Note I have alrea
Creating a PR in JasperReports runs... zero tests?
Gary
On Tue, May 20, 2025 at 4:41 PM Melloware Inc
wrote:
> Note I have already submitted a JasperReports PR against BeanUtils 2.0.0-M1
> months ago but the author doesn't like its an M1.
>
> See: https://github.com/Jaspersoft/jasperreports/pu
Note I have already submitted a JasperReports PR against BeanUtils 2.0.0-M1
months ago but the author doesn't like its an M1.
See: https://github.com/Jaspersoft/jasperreports/pull/488
On Tue, May 20, 2025 at 1:49 PM Gary Gregory wrote:
> Hi Zach,
>
> There is no official or unofficial release d
Hi Zach,
There is no official or unofficial release date yet because I would like to
get more community feedback before we set the API in stone for 2.0.0.
It would be painful if your port from 1.x to 2.x revealed issues requiring
API changes that we couldn't make until 3.x. Would you use 2.0.0-M1
On Tue, May 20, 2025 at 11:24 AM Melloware Inc
wrote:
> I +1 this vote for an official BeanUtils 2.0.0 release. I am using it in
> Production as M1 for months now without issue.
>
Good to know! TY.
Have you tried a snapshot from git master?
It would be good to know if there are any issues ther
I +1 this vote for an official BeanUtils 2.0.0 release. I am using it in
Production as M1 for months now without issue.
On Tue, May 20, 2025 at 10:47 AM Zach Dove wrote:
> Hello,
>
> I’d like to ask about the plans for an official release of BeanUtils2
> (2.0.0 final). We are tracking this for o
Bump???
On 11/13/2020 1:05 PM, Gary Gregory wrote:
I totally forgot about this, I am sorry. I will remember to look this
weekend...
On Fri, Nov 13, 2020, 11:22 Melloware wrote:
Just following up?
On 11/5/2020 1:55 PM, Gary Gregory wrote:
I should be able to take a look on Sunday.
Gary
Sorry... bump :0
On 11/13/2020 1:05 PM, Gary Gregory wrote:
I totally forgot about this, I am sorry. I will remember to look this
weekend...
On Fri, Nov 13, 2020, 11:22 Melloware wrote:
Just following up?
On 11/5/2020 1:55 PM, Gary Gregory wrote:
I should be able to take a look on Sunday
I am looking at other issues and PRs... it might circle back here over the
weekend...
On Fri, Dec 4, 2020 at 8:01 AM Melloware wrote:
> Ping...
>
>
> On 11/13/2020 1:05 PM, Gary Gregory wrote:
> > I totally forgot about this, I am sorry. I will remember to look this
> > weekend...
> >
> > On Fri
Ping...
On 11/13/2020 1:05 PM, Gary Gregory wrote:
I totally forgot about this, I am sorry. I will remember to look this
weekend...
On Fri, Nov 13, 2020, 11:22 Melloware wrote:
Just following up?
On 11/5/2020 1:55 PM, Gary Gregory wrote:
I should be able to take a look on Sunday.
Gary
I totally forgot about this, I am sorry. I will remember to look this
weekend...
On Fri, Nov 13, 2020, 11:22 Melloware wrote:
> Just following up?
>
>
> On 11/5/2020 1:55 PM, Gary Gregory wrote:
> > I should be able to take a look on Sunday.
> >
> > Gary
> >
> > On Thu, Nov 5, 2020, 09:02 Mellow
Just following up?
On 11/5/2020 1:55 PM, Gary Gregory wrote:
I should be able to take a look on Sunday.
Gary
On Thu, Nov 5, 2020, 09:02 Melloware wrote:
PMC Committers,
I know you guys are busy but BeanUtils2 has some great PR's to be
reviewed and merged and this is my _monthly_ plea aski
I should be able to take a look on Sunday.
Gary
On Thu, Nov 5, 2020, 09:02 Melloware wrote:
> PMC Committers,
>
> I know you guys are busy but BeanUtils2 has some great PR's to be
> reviewed and merged and this is my _monthly_ plea asking for a
> BeanUtils2 release that has been 4+ years in the
> On May 25, 2019, at 3:15 PM, Matt Sicker wrote:
>
> Hi, I've gone ahead and approved it after review. Since I'm not active
> in beanutils, I'd prefer someone else to either merge it or add an
> approval review first. My company has also been moving toward
> eliminating vulnerable versions of
Hi, I've gone ahead and approved it after review. Since I'm not active
in beanutils, I'd prefer someone else to either merge it or add an
approval review first. My company has also been moving toward
eliminating vulnerable versions of dependencies, and we use beanutils
(1.9.x currently) in some lim
Hi Matthew,
sorry, I'm quit busy at the moment. I hope to have some more time of OSS at
the end of the year. I'll have a look as soon as I can.
Many thanks for your interest in BeanUtils 2!
Benedikt
2015-10-25 19:34 GMT+01:00 Matthew Mann :
> Pascal,
>
> Thanks for the swift response!
>
> Done:
Pascal,
Thanks for the swift response!
Done: https://issues.apache.org/jira/browse/BEANUTILS-481
-Matt
On Sun, Oct 25, 2015 at 2:26 PM, Pascal Schumacher wrote:
> Hi Matthew,
>
> thanks for the patch. :)
>
> The mailing list does not allow attachments, so the patch was removed from
> the mail
Hi Matthew,
thanks for the patch. :)
The mailing list does not allow attachments, so the patch was removed
from the mail. :(
Please create a issues at
https://issues.apache.org/jira/browse/BEANUTILS/?selectedTab=com.atlassian.jira.jira-projects-plugin:summary-panel
and attach the patch to i
Please consider the attached patch for the commons-beanutils2 project. I
added support for nested properties and automatic conversion. Excerpt
from AutoConversionTest:
*final* DateFormat dateFormat = *new* SimpleDateFormat(" d, ");
*final* TransformerRegistry transformerRegistry = *new*
T
When will BeanUtils2 be released? According to Benedikt Ritter: "One big
part that is still missing is automatic conversion of values." Anything
else?
-Matt
On Wed, Oct 7, 2015 at 1:22 PM, Benedikt Ritter wrote:
> Hello Matthew,
>
> sorry this took so long. We don't have a road map. There is no
Hello Yogesh,
I'll have a look at your patch later this week!
Thanks,
Benedikt
2014-08-14 6:24 GMT+02:00 Yogesh Rao :
> Hi Benedikt,
>
> Have attached the updated patch in JIRA. Please do apply it if everything
> is found okay.
>
> Regards,
> -Yogesh
>
>
> On Wed, Jul 23, 2014 at 11:18 AM, Ben
Hi Benedikt,
Have attached the updated patch in JIRA. Please do apply it if everything
is found okay.
Regards,
-Yogesh
On Wed, Jul 23, 2014 at 11:18 AM, Benedikt Ritter
wrote:
> Hello Yogesh,
>
>
> 2014-07-22 16:42 GMT+02:00 Yogesh Rao :
>
> > Hello Benedikt,
> >
> > I have attached few files
Hello Yogesh,
2014-07-22 16:42 GMT+02:00 Yogesh Rao :
> Hello Benedikt,
>
> I have attached few files with their test cases which can be applied to the
> BU2 trunk if everything is okay :-)
>
> I am working on the rest...
>
Great to hear from you! I'll need some time to look into your patches.
Hello Benedikt,
I have attached few files with their test cases which can be applied to the
BU2 trunk if everything is okay :-)
I am working on the rest...
Regards,
-Yogesh
On Mon, Jun 30, 2014 at 8:26 AM, Yogesh Rao wrote:
> Hi benedikt,
>
> No problem...and yes very much available for deve
Hi benedikt,
No problem...and yes very much available for development..do let me know
what you think on the comment...
Regards
On Monday, June 30, 2014, Benedikt Ritter wrote:
> Yogesh,
>
> sorry it took so long! I had little time for OSS lately... I hope you're
> still up for some BU2 develop
Yogesh,
sorry it took so long! I had little time for OSS lately... I hope you're
still up for some BU2 development ;-)
Best regards,
Benedikt
2014-06-09 4:44 GMT+02:00 Yogesh Rao :
> Hi,
>
> I have updated the thread in JIRA with some of my thoughts ... let me know
> if it aligns so i can help
Hi,
I have added the patch to JIRA issue "SANDBOX-473"
Regards,
-Yogesh
On Fri, Apr 25, 2014 at 6:58 PM, Yogesh Rao wrote:
> Hi Benedikt,
>
> I havent added patches yet wantes ro know if i need to add tht with jira
> created
>
> Regards,
> -Yogesh
>
>
> On Friday, April 25, 2014, Benedikt Rit
Hi Benedikt,
I havent added patches yet wantes ro know if i need to add tht with jira
created
Regards,
-Yogesh
On Friday, April 25, 2014, Benedikt Ritter wrote:
> Hi Yogesh,
>
> thanks for your work on BU2. I'm a bit busy currently, that's why I haven't
> found the time to review your patches.
Hi Yogesh,
thanks for your work on BU2. I'm a bit busy currently, that's why I haven't
found the time to review your patches. I'll try to have a look tomorrow.
Regards,
Benedikt
2014-04-25 10:19 GMT+02:00 Yogesh Rao :
> Hi,
>
> I have added 2 new tasks in JIRA :- SANDBOX-472 & SANDBOX-473
>
>
I would probably create one jira and add a patch to it. Maybe more than one
patch if the changes are really independent.
Gary
Original message From: Yogesh Rao
Date:04/16/2014 03:12 (GMT-05:00)
To: Commons Developers List
Subject: [beanutils2] Automatic Datatype Transfor
Hello Benedikt,
Thanks for the reply ... I will not look at the checkstyle issues for
now... I looked at the mail pointed out earlier by you and will try to work
on it... I do understand now in a nutshell for BU2 to be released it needs
to have the exact same functionality what BU1 had and probabl
Hi Yogesh,
I had problems with the Maven codestyle when I started to contribute to BU2
since most IDE does not support it by default. What helped me was [1] or
[2] respectively. Just want to share this information with you in case who
weren't aware already :-)
[1] https://maven.apache.org/develop
Hello Yogesh and welcome to the dev ML!
Nice that you've decided to help out with the coding in [beanutils2]. I'm
not completely happy with the current check style configuration (which is
derived from the maven project). I'm planning to propose to switch to a
different config this is less verbose
On Sat, Mar 1, 2014 at 6:50 PM, André Diermann wrote:
> But will upgrading to 1.7 will solve the core "issue", that some features
> (in detail: Assertions, MethodUitl and TypeUtil) are copied subsets of
> already implemented features in other Commons projects?
>
Commons Lang actually copied Metho
On Mon, Mar 3, 2014 at 8:36 AM, Benedikt Ritter wrote:
> Okay, so how would you feel if BU2 would depend on Java 7 instead of Java
> 6? Is this acceptable from your PoV?
>
Not that you asked me ;) but I'm OK with that.
Gary
>
>
> 2014-03-03 14:10 GMT+01:00 Adrian Crum >:
>
> > The Assertions
Okay, so how would you feel if BU2 would depend on Java 7 instead of Java
6? Is this acceptable from your PoV?
2014-03-03 14:10 GMT+01:00 Adrian Crum :
> The Assertions class works fine and it serves its purpose. There is no
> need to make the library dependent on another library.
>
> Going that
The Assertions class works fine and it serves its purpose. There is no
need to make the library dependent on another library.
Going that route, as a developer/user of the library, I would be forced
to download and install two libraries instead of one. So it is more
complication and work for me
go for it! :)
http://people.apache.org/~simonetripodi/
http://twitter.com/simonetripodi
On Mon, Mar 3, 2014 at 10:53 AM, Benedikt Ritter wrote:
> Hello André
>
> 2014-03-03 9:57 GMT+01:00 André Diermann :
>
> > 2014-03-03 9:10 GMT+01:00 Benedikt Ritter :
> > >
> > >
> > > The stuff that we hav
On Mon, Mar 3, 2014 at 9:13 AM, Benedikt Ritter wrote:
> Hi,
>
>
> 2014-03-02 11:42 GMT+01:00 Simone Tripodi :
>
> > Hi all,
> >
> > between all options, Matt's one would be the one I'd support.
> >
>
> Shading may be a solution. But tbh I don't see a problem here. We can
> replace Assertions wit
Hello André
2014-03-03 9:57 GMT+01:00 André Diermann :
> 2014-03-03 9:10 GMT+01:00 Benedikt Ritter :
> >
> >
> > The stuff that we have implemented in the Assertions class can be
> replaced
> > by the methods available in Objects from java 7. You're right about
> > MethodUtil and TypeUtil.
> >
>
2014-03-03 9:10 GMT+01:00 Benedikt Ritter :
>
>
> The stuff that we have implemented in the Assertions class can be replaced
> by the methods available in Objects from java 7. You're right about
> MethodUtil and TypeUtil.
>
>
Just to be clear what you mean by replace:
- wrapping the methods from Ob
Hi,
2014-03-02 11:42 GMT+01:00 Simone Tripodi :
> Hi all,
>
> between all options, Matt's one would be the one I'd support.
>
Shading may be a solution. But tbh I don't see a problem here. We can
replace Assertions with Objects. That leaves us with MethodUtil (which
currently only provides dete
Hi André
2014-03-01 19:50 GMT+01:00 André Diermann :
> But will upgrading to 1.7 will solve the core "issue", that some features
> (in detail: Assertions, MethodUitl and TypeUtil) are copied subsets of
> already implemented features in other Commons projects?
>
The stuff that we have implemente
Hi Adrian
2014-03-02 8:03 GMT+01:00 Adrian Crum :
> On 3/1/2014 9:33 AM, Benedikt Ritter wrote:
>
>> I don't like the idea of creating some kind of component hierarchy, where
>> components higher up may depend on lower levels libs. This should be
>> decided for every individual case.
>>
>
> I ag
Hi all,
between all options, Matt's one would be the one I'd support.
All the best,
-Simo
http://people.apache.org/~simonetripodi/
http://twitter.com/simonetripodi
On Sat, Mar 1, 2014 at 8:45 PM, Matt Benson wrote:
> And just to add fuel to the fire and ensure every possible opinion is
> rep
On 3/1/2014 9:33 AM, Benedikt Ritter wrote:
I don't like the idea of creating some kind of component hierarchy, where
components higher up may depend on lower levels libs. This should be
decided for every individual case.
I agree. If I just want some basic low-level library, I don't want it to
And just to add fuel to the fire and ensure every possible opinion is
represented, I agree with Gary, but would support shading after the fact to
reduce the dependency requirements.
Matt
On Mar 1, 2014 1:38 PM, "Paul Benedict" wrote:
> I recommend copying the source of the Commons Lang classes y
I recommend copying the source of the Commons Lang classes you use and
maintain it privately. It is only two classes, right?
On Mar 1, 2014 12:51 PM, "André Diermann" wrote:
> But will upgrading to 1.7 will solve the core "issue", that some features
> (in detail: Assertions, MethodUitl and TypeUt
But will upgrading to 1.7 will solve the core "issue", that some features
(in detail: Assertions, MethodUitl and TypeUtil) are copied subsets of
already implemented features in other Commons projects?
>From what I can see commons.lang3 is already referenced by BU2 (although
it's currently only use
On Sat, Mar 1, 2014 at 12:33 PM, Benedikt Ritter wrote:
> I don't like the idea of creating some kind of component hierarchy, where
> components higher up may depend on lower levels libs. This should be
> decided for every individual case.
>
> In the case of BU2 I'd say it's better to change the
I don't like the idea of creating some kind of component hierarchy, where
components higher up may depend on lower levels libs. This should be
decided for every individual case.
In the case of BU2 I'd say it's better to change the language level
requirement to 1.7. We could use Objects.notNull.
Ot
Simon, that makes totally sense to me :) ..that's why I also often struggle
to use StringUtils for instance... but it starts with only one method and
after some time I find myself in having copied a lot of methods.
That's why I like Gary's idea too. Regarding BU2, MethodUtil and TypeUtil
are also
I should clarify that I see components like [io] and [lang] as lower level
than [beanutils] for example.
Gary
On Sat, Mar 1, 2014 at 11:32 AM, Gary Gregory wrote:
> My preference would be for components like [io] and [lang] to be reused
> from other components as a dependency in order to avoid
My preference would be for components like [io] and [lang] to be reused
from other components as a dependency in order to avoid this kind of
duplication.
Gary
On Sat, Mar 1, 2014 at 11:27 AM, André Diermann wrote:
> Hello,
>
> I noticed that the majority (all?) functionality of the Assertions c
Salut André,
to avoid to depend to an external lib just to get benefit of 3 methods :)
Best,
-Simo
http://people.apache.org/~simonetripodi/
http://twitter.com/simonetripodi
On Sat, Mar 1, 2014 at 5:27 PM, André Diermann wrote:
> Hello,
>
> I noticed that the majority (all?) functionality of t
Hello André
2014-02-16 12:32 GMT+01:00 André Diermann :
> Hello Benedikt,
>
> I investigated the AccessibleObjectsRegistry class. I found some potential
> improvements. I submitted by suggestions on how to improve those to Jira
> [1]. Since this is my first commit ever to ASF I am afraid I did s
Hello Benedikt,
I investigated the AccessibleObjectsRegistry class. I found some potential
improvements. I submitted by suggestions on how to improve those to Jira
[1]. Since this is my first commit ever to ASF I am afraid I did something
wrong. Please tell me, if I messed something up. O:)
What
One thing I would prefer in a BeanUtils 2 is the removal of static utility
classes. I like beans; they allow me to subclass and customize. I can't do
that with static access.
On Wed, Feb 12, 2014 at 2:43 PM, Benedikt Ritter wrote:
> Hell André
>
>
> 2014-02-11 20:01 GMT+01:00 André Diermann :
>
Hell André
2014-02-11 20:01 GMT+01:00 André Diermann :
> Hi Benedikt,
>
> many thanks for your kind introduction. :-) I also think jumping into the
> code will do most, that's where I start for now. What I have seen so far
> looks quite promising, especially the test coverage, hence it's maybe h
Hi Benedikt,
many thanks for your kind introduction. :-) I also think jumping into the
code will do most, that's where I start for now. What I have seen so far
looks quite promising, especially the test coverage, hence it's maybe hard
for me to find big improvements. ... you mentioned a requiremen
Hello André,
nice that you're interested in BU2, welcome to this list.
2014-02-11 12:26 GMT+01:00 André Diermann :
> Hi,
>
> I stumbled upon the BeanUtils2 project which looks quite interessing to me.
> Do you have any future plans? (When) Will it replace the BeanUtils
> component?
>
We don't
Hi Bene,
sounds a good plan, go for it and we'll follow up the discussion once
applying the the patch.
TIA,
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Mon, Aug 13, 2012 at 9:47 PM, Benedikt Rit
Hi,
2012/8/13 Adrian Crum :
> http://ci.apache.org/projects/ofbiz/site/javadocs/org/ofbiz/base/util/cache/package-summary.html
>
thanks for the input! As far as I understand the LRUMap seems to be
more appropriate than a map using some sort of reference. But I'll
have a look anyway!
The LRUMap f
http://ci.apache.org/projects/ofbiz/site/javadocs/org/ofbiz/base/util/cache/package-summary.html
-Adrian
On 8/13/2012 2:51 PM, Simone Tripodi wrote:
Hi Adrian,
any direct link? TIA!
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonet
Commons Collections has an LRUMap class that we could "borrow", perhaps?
On Mon, Aug 13, 2012 at 8:07 AM, Simone Tripodi
wrote:
> guten morgen Bene,
>
> I have not a strong opinion about it, I am convinced anyway that the
> original BU authors (BU2 at the beginning was a tentative to refurbish
>
Hi Adrian,
any direct link? TIA!
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Mon, Aug 13, 2012 at 3:19 PM, Adrian Crum
wrote:
> Apache OFBiz has a soft reference cache implementation.
>
> -Adria
Apache OFBiz has a soft reference cache implementation.
-Adrian
On 8/13/2012 1:07 PM, Simone Tripodi wrote:
guten morgen Bene,
I have not a strong opinion about it, I am convinced anyway that the
original BU authors (BU2 at the beginning was a tentative to refurbish
BU) adopted the WeakHashMap
guten morgen Bene,
I have not a strong opinion about it, I am convinced anyway that the
original BU authors (BU2 at the beginning was a tentative to refurbish
BU) adopted the WeakHashMap NOT with the purpose of implementing a
`cache` in the strict sense we are used to. We should go back to the
ML
Hi Bene,
sounds a reasonable approach. Let's see where the experiment brings us! :)
TIA,
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Tue, Jun 26, 2012 at 11:34 AM, Benedikt Ritter
wrote:
> Hey
Hey Simo,
thanks for the feedback. I hope that you could make your deadline ;-)
I'll implement that ASAP. Just one comment:
2012/6/25 Simone Tripodi :
> Hi Bene,
>
[SNIP]
>
> that is fine, but just throw the expected exception, no needs to throw
> an IllegalAccessException first.
>
To keep code
Hi Bene,
> I'm still working on https://issues.apache.org/jira/browse/SANDBOX-423
> and I wanted to test if all the new exception get thrown correctly.
> For that reason I implemented a new class - ExceptionThrowingTestBean
> that properties and methods that throw exceptions when they get
> called
Hi Simo,
2012/6/21 Simone Tripodi :
> Hi Bene,
>
> I'll need some time to read you email, I am close to a deadline and
> still have few task to complete.
>
no problem!
> In the meanwhile, I'd sugest you to move exceptions outside the
> `exception` package and drop it - exceptions should be packa
Hi Bene,
I'll need some time to read you email, I am close to a deadline and
still have few task to complete.
In the meanwhile, I'd sugest you to move exceptions outside the
`exception` package and drop it - exceptions should be packaged at
APIs level, not by their nature.
Have a look, just to m
Hi James,
I think that analyzed cases by Benedikt still sound good, adding
'semantic' for each defined exception.
I wouldn't expect users will be forced on try/catch blocks... anyway I
suggest to start with Bene's codebase and refine it while working on
BU2, depending of how the component evolves
> Now I'm thinking
> that it might be a better approach to handle exception where they
> first appeared. For example we could catch the NoSuchMethodException
> in DefaultBeanProperties. That would scatter the exception handling
> everywhere around in the code, but it would reduce the overhead in
>
I thought folks agreed to stick with one generic exception and only add
when it makes sense. Does this really make sense? That is a rather large
hierarchy. Are people really going to put catch blocks for any of those
specific exceptions?
Sent from tablet device. Please excuse typos and brevit
2012/6/19 Simone Tripodi :
>> The point is with "Property %s not found in %s type" you're embedding the
>> relevant data in the message text and a client would have to parse the text
>> if a special handling is required.
>
> I would never force poor users parsing the exception message to
> understa
2012/6/18 Simone Tripodi :
> +1 to 'of'
>
> short to type and intuitive!
>
> Thanks Matt for the valuable feedbacks!
>
I'll implement that after I'm finished with replacing the exceptions.
Benedikt
> best,
> -Simo
>
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.co
2012/6/19 Simone Tripodi :
> Hello,
>
>> I remember, that we added the internal package, because we had the
>> need to split up the code base. Looking at the code base now, I don't
>> see any reason for the internal package. Can we move Assertions back
>> to the main package and remove the internal
> The point is with "Property %s not found in %s type" you're embedding the
> relevant data in the message text and a client would have to parse the text
> if a special handling is required.
I would never force poor users parsing the exception message to
understand what is wrong - I would add gett
Hi Simo,
Simone Tripodi wrote:
> A suggestion:
>
> we are often using the String.format() method to format Exception
> messages - which is very good, IMHO - and since we are introducing a
> new Exception we can take advantage for reducing its use, centralizing
> the messag
A suggestion:
we are often using the String.format() method to format Exception
messages - which is very good, IMHO - and since we are introducing a
new Exception we can take advantage for reducing its use, centralizing
the message format in the new exception itself, h
Hello,
> I remember, that we added the internal package, because we had the
> need to split up the code base. Looking at the code base now, I don't
> see any reason for the internal package. Can we move Assertions back
> to the main package and remove the internal package?
yes, I am taking care o
Hi Simo,
Simone Tripodi wrote:
[snip]
>>> A suggestion:
>>>
>>> we are often using the String.format() method to format Exception
>>> messages - which is very good, IMHO - and since we are introducing a
>>> new Exception we can take advantage for reducing its use, centralizing
>>> the message fo
Hi,
I've started to implement BeanReflectionException and I want to take
the approach Simone suggested with the ErrorMessage from Digester. Now
I have a problem: If I want to pass the throwable cause as well, that
parameter has to be before the varargs argument. This would result in
the following
+1 to 'of'
short to type and intuitive!
Thanks Matt for the valuable feedbacks!
best,
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
---
Just for the sake of multiple choice, what about:
- keyedBy
- keyedTo
- withKey
- of
- at
?
Matt
On Mon, Jun 18, 2012 at 7:19 AM, Simone Tripodi
wrote:
> LOL indeed :)
>
> go for your proposed solution, sounds nice anyway :)
>
> alles gute,
> -Simo
>
> http://people.apache.org/~simonetripodi/
LOL indeed :)
go for your proposed solution, sounds nice anyway :)
alles gute,
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Mon, Jun 18, 2012 at 11:10 AM, Benedikt Ritter
wrote:
> I just realize
Sounds even better!
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Mon, Jun 18, 2012 at 12:33 PM, James Carman
wrote:
> BeanReflectionException?
>
> Sent from tablet device. Please excuse typos and
BeanReflectionException?
Sent from tablet device. Please excuse typos and brevity.
On Jun 18, 2012 4:30 AM, "Simone Tripodi" wrote:
> Guten morgen, Bene,
>
> > My personal favorite is ReflectionException. I don't think, that we
> > should prefix classes wie BeanUtils*, because this information
I just realized, that we cannot call a method
MappedPropertyAccessor.for(String key) - "for" is a reserved keyword
;-)
How about:
MappedPropertyAcessor.forKey(String key) and
ArgumentsAcessor.with(Argument... Arguments)
Benedikt
2012/6/16 Simone Tripodi :
> +1 to James for both topics,
>
> let's
Guten morgen, Bene,
> My personal favorite is ReflectionException. I don't think, that we
> should prefix classes wie BeanUtils*, because this information is
> contained in the fully qualified class name.
+1 I wouldn't happy at all to add a BeanUtilsException,
ReflectionException sounds the good
+1 to James for both topics,
let's start from a basic exception - naming proposals are welcome.
I'll create the wiki page later after dinner - that WE is too much
sunny to stay at home ;)
best,
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.co
It shouldn't. If you're catching the superclass (for instance
BeanUtilsReflectionException) and later we start to throw
BeanUtilsInstantiationException which extends
BeanUtilsReflectionException, I don't think you'll run into problems.
On Fri, Jun 15, 2012 at 10:26 AM, Benedikt Ritter
wrote:
> 2
2012/6/15 James Carman :
> On Fri, Jun 15, 2012 at 9:39 AM, Benedikt Ritter
> wrote:
>> - Wrapper Exceptions: I thing we should discuss, how a exception
>> hierarchy could look like. I'll make a suggestion ASAP.
>>
>
> I don't want to duplicate the hierarchy. I would say start with a
> generic ex
On Fri, Jun 15, 2012 at 9:39 AM, Benedikt Ritter
wrote:
> - Wrapper Exceptions: I thing we should discuss, how a exception
> hierarchy could look like. I'll make a suggestion ASAP.
>
I don't want to duplicate the hierarchy. I would say start with a
generic exception type for now. If folks ask f
Hi,
I agree with what you said.
- Annotation processing: let's keep that in mind, and come back to it
later. Simo, can you create the wiki page for us?
- Renaming methods: I hope that I get the time to create a patch this weekend
- Wrapper Exceptions: I thing we should discuss, how a exception
Thanks a lot for monitoring BU2 James, and thanks for the feedbacks!
this sounds to be the way to go!
now waiting for patches from Benedikt :)
best,
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On F
On Fri, Jun 15, 2012 at 1:50 AM, Simone Tripodi
wrote:
>
>
> > 2. Wrap checked exceptions into RuntimeExceptions. The question is,
> > what a user can do to recover from one of those exceptions. Only if
> > there is something the user can do, it would make sense to throw a
> > checked exception.
>
Hi Bene,
> Hi,
>
> while working on BU2, I was thinking about the API and what may be improved.
>
great! :)
> Exceptions:
> Right now a lot of API methods just populate the checked reflection
> exceptions like InvocationTargetException from the native java
> reflection API. This dooms Java 6 use
100 matches
Mail list logo
