Re: Is JEXL an active project ?
> I've updated https://issues.apache.org/jira/browse/JEXL-55 , a big patch on > the 2.0 svn branch. > Any review/comment welcome. I'll try to have a look at it during this week and apply or come back with questions, if any. Cheers + Thanks, Christian - 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 ChainedTransformer implements Transformer, Serializable
So, does this mean that a ChainedTransformer always has to have the
same input and output types? Transformer is declared as:
public interface Transformer {
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 ChainedTransformer implements Transformer
{
public ChainedTransformer(Transformer initial);
public O transform(I input);
public ChainedTransformer append(Transformer 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
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 : > 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
Re: Spec compliance as new Commons component
On Wed, Jun 3, 2009 at 2:22 AM, sebb wrote: > On 02/06/2009, Niklas Gustavsson 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: 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 schrieb am Do, 7.5.2009:
> Von: Mark Struberg
> Betreff: Re: proposal for performance/usability optimisations in
> commons.lang.Validate
> An: "Commons Developers List"
> 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
> 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
> 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
> true
> > > *
> > > * @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.len
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: [vfs] MemcachedFilesCache for Google App Engine (object serialization)
In order to solve this serialization problem, I'm trying to understand exactly what the FilesCache is used for. Most importantly, I'm trying to determine whether the FilesCache is used to cache file content. 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. I came to this conclusion based on the DefaultFileContent class, where the input and output streams are stored in a ThreadLocal variable. If my understanding is correct, then my task is greatly simplified. Do I understand this properly? Thanks. On Thu, Jun 4, 2009 at 5:22 PM, Vince Bonfanti wrote: > I'm investigating creating a memcached-based FilesCache implementation for > use with Google App Engine. The basic obstacle is that this requires that > all objects that are used as keys or values must be serializable. Before I > go too far down this path, I'd like to know if this is a reasonable thing to > do (or consider doing). Any thoughts or guidance would be greatly > appreciated. > > Background info: the Google App Engine (GAE) environment is inherently > distributed, where an unknown number of multiple instances of your > servlet-based web application will be running at the same time. The GaeVFS > project (http://gaevfs.appspot.com) implements a VFS plugin on top of the > GAE datastore; this is needed because the "real" filesystem within GAE is > read-only, so GaeVFS provides a writeable filesystem for use by > applications. It seems that for proper operation of VFS, the FilesCache > implementation used by GaeVFS should (must?) also be inherently distributed. > Fortunately, GAE supplies a memcached API that will be perfect for this use > (if I can solve the serialization problem). > > Here's my first cut at what classes I'd need to make serializable and some > notes on which fields might be marked transient: > > *AbstractFileName* > serialized fields: scheme (String), absPath (String), type (FileType) > transient fields: uri, baseName, rootUri, extension, decodedPath > > *FileType* > serialized fields: name (String), hasChildren (boolean), hasContent > (boolean), hasAttrs (boolean) > transient fields: none > > *AbstractFileObject* > serialized fields: name (AbstractFileName), content (DefaultFileContent) > transient fields: fs (AbstractFileSystem), operation (FileOperations), > attached (boolean), type (FileType), parent (FileObject), children > (FileName[]), objects (List) > > It's very important the the fs (AbstractFileSystem) field be transient to > limit the number of other classes that need to be made serializable. It > looks like files are always retrieved from the files cache via the > AbstractFileSystem.getFileFromCache() method; if so then the "fs" field of > AbstractFileObject can be restored within this method and doesn't need to be > serialized. We'll need to define a package-scope > AbstractFileObject.setFileSystem() method to support this. Or, this could be > done within the MemcachedFilesCache.getFile() method before returning the > FileObject (but then we'd need a FileObject.setFileSystem method, or do some > not-very-nice type casting). > > *DefaultFileContent > *serialized fields: file (AbstractFileObject), attrs (Map), roAttrs (Map), > fileContentInfo (FileContentInfo), fileContentInfoFactory > (FileContentInfoFactory), openStreams (int) > transient fields: threadData (ThreadLocal) > question: what types do the "attrs" and "roAttrs" maps contain? are these > serializable? > question: FileContentInfo and FileContentInforFactory are interfaces, what > are the implementations of these? >
