Hi all,
I understand and agree with you about your doubts - I don't have a
strong idea, anyway I wouldn't take the *Handler as first choice,
since it does not drive users to an event-handler alike programming
model, rather *Operations makes more sense...
+1
Furthermore I think that name
Hi,
now that we have implemented describe() and populate() on
DefaultBeanAccessor, cloneBean() and copyProperties(T target) seem very
easy to implement. I would realize cloneBean() simply like:
public B cloneBean()
throws aLotOfExceptions ;-)
{
@SuppressWarnings( unchecked )
B
If we jump to java 7, we can clean up our exceptions by using
ReflectiveOperationException.
Sent from tablet device. Please excuse typos and brevity.
On Feb 12, 2012 6:28 AM, Benedikt Ritter b...@systemoutprintln.de wrote:
Hi,
now that we have implemented describe() and populate() on
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.
Project commons-digester3 has an issue affecting its community integration.
This
Hi Sebb,
Sorry, -1: I get a build failure with my default set up using
https://repository.apache.org/content/repositories/orgapachecommons-218/commons-net/commons-net/3.1/
*commons-net-3.1-src.zip*. The checkstyle XML files are missing.
Apache Maven 3.0.4 (r1232337; 2012-01-17 03:44:56-0500)
Hello Marco,
I understand and agree with you about your doubts - I don't have a
strong idea, anyway I wouldn't take the *Handler as first choice,
since it does not drive users to an event-handler alike programming
model, rather *Operations makes more sense...
+1
c00l :)
Furthermore I think
Hi Bene,
public B cloneBean()
throws aLotOfExceptions ;-)
{
@SuppressWarnings( unchecked )
B clone = (B) bean.getClass().newInstance();
DefaultBeanAccessorB cloneAccessor = new DefaultBeanAccessorB( clone
);
cloneAccessor.populate( this.describe() );
return clone;
}
Hola,
Would it be so terrible to maintain such redundancy?
IMHO, yes, because:
* it has to be applied in each class of algorithms we support;
* switching to proposed APIs, would proliferate that APIs in each algorithm;
* weight types are driven by generics, so users cannot bind wrong
Hi Simone,
Would it be so terrible to maintain such redundancy?
IMHO, yes, because:
* it has to be applied in each class of algorithms we support;
* switching to proposed APIs, would proliferate that APIs in each algorithm;
* weight types are driven by generics, so users cannot bind
Hi,
same problem with site generation here.
In addition to Gary's findings I just noticed a very minor detail: The
Built-By header in the manifest does not contain the actual user name,
but just the text 'User'. Was this intended?
Oliver
Am 12.02.2012 17:09, schrieb Gary Gregory:
Hi Sebb,
Am 12.02.2012 18:28, schrieb Simone Tripodi:
Hi Bene,
Hi!
[...]
copyProperties() can be implemented likewise. Is that really all we have to
do, or am I missing something? I've looked at BeanUtils1 and they are
handling Maps a little differently by coping all entries. So I guess we have
to
Hi guys,
* the mapping between primitive types and their respective default
*Operations is known and kept somewhere (abstract class, etc);
* each algorithm specifies only once the set of primitive types that
it accepts;
* with a bit of magic (?) we combine the above to provide shortcuts
Hi Bene,
yes I did (as I said ;-). So I guess, that we can implement it the way I
said, but make sure Maps will be handled the way they were in BeanUtils1.
that would be acceptable since users are already used to that behavior
Any thoughts about what James suggested? Just having to
Hi *,
while the idea is fine, it is not clear to me how you intend
implementing it. Please fill an issue and attach a patch so we can
discuss also about the how and not only what :)
best,
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
Online report :
http://vmbuild.apache.org/continuum/buildResult.action?buildId=18732projectId=75
Build statistics:
State: Failed
Previous State: Ok
Started at: Sun 12 Feb 2012 21:40:59 +
Finished at: Sun 12 Feb 2012 21:41:43 +
Total time: 44s
Build Trigger: Schedule
Build
Hi,
* the mapping between primitive types and their respective default
*Operations is known and kept somewhere (abstract class, etc);
* each algorithm specifies only once the set of primitive types that
it accepts;
* with a bit of magic (?) we combine the above to provide shortcuts to
Hola Claudio,
the patch you mentioned was something I would have asked you, before or later :P
Since we are on topic: is there any particular reason why Zero.zero()
can not be part of Semigroup interface? Or better: is there any
benefit we can get from keeping Zero and Semigroup separated?
TIA,
Hi Simone,
the patch you mentioned was something I would have asked you, before or later :P
I know I can read your mind :)
Since we are on topic: is there any particular reason why Zero.zero()
can not be part of Semigroup interface? Or better: is there any
benefit we can get from keeping
Thanks to all who contributed to this thread. I thought it might be
useful to summarize the discussion so far.
Preferences have been expressed for:
- java.util.logging (jul)
- commons logging (cl)
- SLF4J
General
- Logging in pool, if any, should be minimal
jul
- Anything other than jul adds
2012/2/13 Mark Thomas ma...@apache.org:
General
- Logging in pool, if any, should be minimal
Two general questions:
When there are several pools,
- is it possible to discern log messages from different pools?
- is it possible to control logging level for a single pool, or all
pools have the
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.
Project commons-email has an issue affecting its community integration.
This
On 12 February 2012 16:09, Gary Gregory garydgreg...@gmail.com wrote:
Hi Sebb,
Sorry, -1: I get a build failure with my default set up using
https://repository.apache.org/content/repositories/orgapachecommons-218/commons-net/commons-net/3.1/
*commons-net-3.1-src.zip*. The checkstyle XML files
On 12 February 2012 20:42, Oliver Heger oliver.he...@oliver-heger.de wrote:
Hi,
same problem with site generation here.
In addition to Gary's findings I just noticed a very minor detail: The
Built-By header in the manifest does not contain the actual user name, but
just the text 'User'. Was
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.
Project commons-digester3 has an issue affecting its community integration.
This
On 13 February 2012 02:01, sebb seb...@gmail.com wrote:
On 12 February 2012 16:09, Gary Gregory garydgreg...@gmail.com wrote:
Hi Sebb,
Sorry, -1: I get a build failure with my default set up using
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.
Project commons-proxy-test has an issue affecting its community integration.
This
We have 3 +1's from Mark, Luc and Mladen
Thus the vote passed. I'll push the sources
and create an ANN later today.
Regards
--
^TM
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail:
27 matches
Mail list logo
