AW: [vfs] MemcachedFilesCache for Google App Engine (object serialization)
Hi! I think the answer is: the FilesCache is used to optimize resolveFile() performance, and to reuse FileObject instances, but is not used to cache the actual file content. Thats correct! Ciao, Mario - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: proposal for performance/usability optimisations in commons.lang.Validate
Hiho!
I wrote a version based on the mirror on github which is available here:
http://github.com/struberg/commons-lang/commit/ed8515f63290eba6e38ff5b79772e87b27dde32b
I will create a JIRA and also attached a patch for those not familiar with git.
LieGrue,
strub
--- Mark Struberg strub...@yahoo.de schrieb am Do, 7.5.2009:
Von: Mark Struberg strub...@yahoo.de
Betreff: Re: proposal for performance/usability optimisations in
commons.lang.Validate
An: Commons Developers List dev@commons.apache.org
Datum: Donnerstag, 7. Mai 2009, 11:23
Thanks a lot Henri!
I talked with Shawn Pearce about possible performance
issues and we now ended up with 3 function
groups:
notNull(Object)
notNull(Object, String)
notNull(Object, String, Object...);
So the JVM doesn't need to create an Object[] if we only
like to provide a single String message.
I think we could do the same for all the notNull(Object,
String, Integer) for binary compatibility
although I believe this will make the library more complex
to use. And since the packages will
change too ...
In any case we should do 2 things (also for the 'old'
functions with (Object, String, Integer) or
whatever). Remember ALL those things will happen _only_ if
the validation fails, so we don't have
to care about performance - we don't need to fail fast ;)
1.)
if (o == null ) {
if (msg contains {0} or something that indicates the
use of MessageFormat) {
use MessageFormat;
} else {
use msg + : + msgIntParam;
}
}
So this should then even be compatible to use for 'old'
invocations where one doesn't like to use
the MessageFormat feature.
wdyt?
Patch will follow in about ~1-2 weeks.
txs and LieGrue,
strub
--- Henri Yandell flame...@gmail.com
schrieb:
trunk/ is now JDK 5 focused. It'll be Lang 3.0, but is
very unlikely
to keep the same package naming.
My biggest concern with ellipsis code is that null
moves from being
null to being null inside an Object[]. So we could see
some
unnecessary API changing if we're not careful.
Otherwise - the below sounds good and a JIRA issue
with a patch would rock :)
Thanks,
Hen
On Sat, May 2, 2009 at 10:06 AM, Mark Struberg strub...@yahoo.de
wrote:
Hi!
I'm a long time user (and big fan) of
commons.lang.Validate because it's a very neat pattern
for getting stable software modules.
I'm PMC member on Apache OpenWebBeans and
currently also writing the maven-scm-provider-jgit
(JGIT is a native Java implementation of GIT). Since
jgit-core (the part of EGIT we use for the
maven-scm-provider-jgit) is BSD and Shawn likes to
have not too much external dependencies, I
started writing my own little Validate helper class
and had a hopefully good idea which imho
would also be a good extension to
commons.lang.Validate:
A main problem on validation is the message
creation which costs a lot of String operations
and therefor also garbage collection. I've now seen
that the latest version in SVN has an
additional object parameter for a few functions which
addresses this problem. My proposal now
goes even further but requires java-5 since it uses
ellipsis notation.
If msgObject[0] is a String
java.text.MessageFormat will be used for creating the
failure
message, e.g.
Validate.notNull(nullInt, testMessageText
Integer={0} btw! and Integer2={1}., new
Integer(42), new Integer(43));
example for isTrue with message construction:
/**
* Validate that b is
codetrue/code
*
* @param b boolean to validate
* @param msgObjects additional Objects added as
text message to the InvalidArgumentException
*/
public static void isTrue(boolean b, Object...
msgObjects) {
if (!b) {
throw new
IllegalArgumentException(getMessage(msgObjects));
}
}
/**
* private helper function to create an error
message from the given Objects
* If the first object in msgObjects is of type
{...@code String} then
* {...@code MessageFormat} will be used to format
the output message.
*
* @param msgObjects
* @return concatenated String representation of
all the objects
*/
private static String getMessage(Object...
msgObjects) {
if (msgObjects.length 0
msgObjects[0] instanceof String) {
MessageFormat form = new
MessageFormat((String) msgObjects[0]);
Object[] params = new
Object[msgObjects.length - 1];
System.arraycopy(msgObjects, 1, params, 0,
msgObjects.length - 1);
return
form.format(params);
}
else {
StringBuffer sb = new
StringBuffer(Validation failed: [);
for(int i = 0; i
msgObjects.length; i++) {
if (i 0)
{
sb.append(' ');
}
Re: Spec compliance as new Commons component
On Wed, Jun 3, 2009 at 2:22 AM, sebbseb...@gmail.com wrote: On 02/06/2009, Niklas Gustavsson nik...@protocol7.com wrote: Interesting. Could be useful for parts of Commons Codec, Mail, Net. Seems to me it fits in with the Commons charter, and other projects that could benefit from it (e.g. Tomcat, HttpComponents) may well already be using other Commons components. So, if we would like to move forward on this (just checking, we have not formally voted over at MINA), what would be the procedure? /niklas - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all] Re: [jira] Created: (MATH-275) MANIFEST.MF contains incorrect Import-Package OSGi header (makes it unusable for OSGi)
2009/6/6 Phil Steitz phil.ste...@gmail.com: Can one of our OSGI experts pls look into this? If what the reporter is saying is correct, all of our jars built using m2 are similarly unuseable I've added a response to the JIRA ticket - not that I'm an OSGi expert, but its come up before and what were doing is following the advice from Apache Felix Niall Thanks! Phil Paul Field (JIRA) wrote: MANIFEST.MF contains incorrect Import-Package OSGi header (makes it unusable for OSGi) Key: MATH-275 URL: https://issues.apache.org/jira/browse/MATH-275 Project: Commons Math Issue Type: Bug Affects Versions: 1.2 Reporter: Paul Field The MANIFEST.MF file contains this OSGi header: Import-Package: org.apache.commons.discovery.tools, org.apache.commons.math;version=1.2, org.apache.commons.math.analysis;version=1.2, org.apache.commons.math.complex;version=1.2, ... This header defines what the bundle requires from the OSGi runtime and so it shouldn't include the packages defined in the bundle (i.e. all the org.apache.commons packages). I suspect it shouldn't include the org.apache.commons.discovery.tools package either as I can't see that math has a dependency on that (I could be wrong :-) ). The presence of this header causes the Math library to be unusable as an OSGi bundle in Eclipse RCP development (and I suspect in any OSGI container). - 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
[collections] ChainedTransformer...
All,
I thought I'd check out the collections_jdk5_branch to see if there
was anything that I could tinker with. I decided to look into the
functors, since that's what I'm mainly interested in. Immediately I
noticed ChainedTransformer. It's declared as:
public class ChainedTransformerT implements TransformerT, T, Serializable
So, does this mean that a ChainedTransformer always has to have the
same input and output types? Transformer is declared as:
public interface TransformerI, O {
public O transform(I input);
}
Shouldn't it support different input/output types?
What I was thinking about would be a new way to think about these chains:
public class ChainedTransformerI,O implements TransformerI,O
{
public ChainedTransformer(TransformerI,O initial);
public O transform(I input);
public T ChainedTransformerI,T append(TransformerO,T next);
}
Typically, to create a ChainedTransformer, you have to put your
transformers in a collection and pass them in to create one. This
way, instead of having to create a new collection, you'd just append
as you go. What do you think?
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
