Clouduser,
(that doesn't taste like a name),
provided a is in context of type A and class A has a getter getB() then ${A.b}
gives you the return of getB().
That's how I always accessed nested java objects.
I don't understand your XML-example though... at least not its relevance for
jexl.
Can
--
From: Mladen Turk mt...@apache.org
Sent: Thursday, October 21, 2010 12:57 AM
To: Commons Developers List dev@commons.apache.org
Subject: [VOTE] Release Daemon 1.0.4 based on RC1
Hi,
Commons Daemon 1.0.4 RC1 release is available for testing
On 10/21/10 3:57 AM, Mladen Turk wrote:
Hi,
Commons Daemon 1.0.4 RC1 release is available for testing at:
http://people.apache.org/~mturk/daemon/
The SVN tag is:
https://svn.apache.org/repos/asf/commons/proper/daemon/tags/COMMONS_DAEMON_1_0_4_RC1
(If voted will be renamed to
Hi all mates,
I updated the jira issue uploading my patch; it contains the
configuration extraction and some code modification.
IMHO we shouldn't replicate the same data in both configuration AND
factory/pool, when creating the factory/pool it is enough storing the
configuration reference, just
Mladen Turk wrote:
With my vote we have 5 binding votes.
(Sebastian, Niall, Phil, Bill and I)
You had 6:
http://thread.gmane.org/gmane.comp.jakarta.commons.devel/116173/focus=116189
- Jörg
-
To unsubscribe, e-mail:
On 10/25/2010 02:42 PM, Jörg Schaible wrote:
Mladen Turk wrote:
With my vote we have 5 binding votes.
(Sebastian, Niall, Phil, Bill and I)
You had 6:
http://thread.gmane.org/gmane.comp.jakarta.commons.devel/116173/focus=116189
Sorry I was automatically rule out non @apache.org address
Hi Simone,
You have two +1's waiting for you in the JIRA comments =)
My comments from tracker:
I took a look at this last night but didn't get a chance to comment =)
I like the patch, I believe this does indeed satisfy the issue.
One question I have, since we're eliminating the primitive
Dear Apache Commons IO developers,
I found there might be a close method missing in the source code of test cases,
which may be an issue.
No patch seems to be applied till revision 1026932.
How do you guys think?
The original code here is:
In
Hi Steven,
very sorry to have missed the Jira notifications, just checked now
after read your email. Sorry! :(
I thought the idea was adding JMX support directly on factory/pool and
not on Configuration, btw not being JMX expert this will be a good
chance to learn... I'll fill a new Jira issue
Simone,
I'm sorry I'm confusing, so many thoughts going though my mind =)
yes, I think the best approach is to provide a separate class for the
JMX...but I'm thinking that doing a private inner class (non-static) in each
pool would be the cleanest way to do so. This way, the MBean (instance)
Hi Steven :)
thanks for the explanation, as far as I understand there are a lot of
things I can learn from you about JMX so I started feeling impatient
to see your commits :P
I don't think we should mark with @Deprecate removed ctors, classes
are now living in a fresh new package so, as user, I
What do you folks think about making the exceptions extend
RuntimeException in 2.0? I really find it tedious to do try/catch
everywhere I want to ask a FileObject something (like if it exists or
not).
-
To unsubscribe, e-mail:
+1 on this issue.
I use VFS on a couple projects and this is always a bit burdensome, and on
several occasions have indeed caught and rethrew RuntimeExceptions. Even if
we can't/shouldn't soften them, what about typing them to be more specific?
Having every method throwing a FileSystemException
On 10/25/10 10:51 AM, Steven Siebert wrote:
Simo,
You make a good point, especially with the groupId/package change.
POOL-169 did implement some deprecations for changes from 1.5 to 2.0, so
this isn't without precedent and consistency (even for the sake of
consistency in commons-* subprojects,
Phil,
I don't think we have removed the ability to access the config options
programmatically from the config instance. You can either get a reference
to it post-construct/build or from the getConfig() method on the pool.
Non-config properties remain the same, accessible through the pool API.
Thank you for working through this Simone.
I would like to discuss something I took for granted in my experimental patch
for [POOL-173]. I can see that you took and a more conservative (and safer ;)
approach in your version. I am glad to see this because we can now more easily
discuss it
On 10/25/10 11:22 AM, Steven Siebert wrote:
Phil,
I don't think we have removed the ability to access the config options
programmatically from the config instance. You can either get a reference
to it post-construct/build or from the getConfig() method on the pool.
Non-config properties
Gary,
I tossed this around as well, and noted these fields as a possible promote
to the Abstract configuration, because I agree that there probably isn't a
good reason why one pool has those features and the other doesn't. (if
this is indeed the case, these would probably best be tracked in two
On Oct 25, 2010, at 8:10 AM, James Carman wrote:
On Mon, Oct 25, 2010 at 11:05 AM, Gary Gregory
ggreg...@seagullsoftware.com wrote:
Do we want the APIs to be quieter than using java.io.File for example? Or,
should exceptions be thrown from similar places?
Definitely quieter than
On 10/25/10 11:26 AM, Gary Gregory wrote:
Thank you for working through this Simone.
I would like to discuss something I took for granted in my experimental patch
for [POOL-173]. I can see that you took and a more conservative (and safer ;)
approach in your version. I am glad to see this
true =) BTW, I'll be at ApacheCon, if the VFS crew would like another warm
body to assist in getting the release out. Just let me know when/where to
be
On Mon, Oct 25, 2010 at 11:49 AM, Ralph Goers ralph.go...@dslextreme.comwrote:
On Oct 25, 2010, at 8:10 AM, James Carman wrote:
On Mon,
+1 for softening all exceptions. The fact is, what reasonable recourse
is there to the user if a file operation fails? That's what checked
exceptions were supposed to be for -- mandate handling code. It's
tough to say we need to mandate handling these errors.
Paul
On Mon, Oct 25, 2010 at 10:49
On Mon, Oct 25, 2010 at 11:49 AM, Ralph Goers
ralph.go...@dslextreme.com wrote:
I'm not in favor of changing much at this point. I'd really like to get a
release done without too many more changes.
There's a problem with that, Ralph. If we publish a 2.0, we can't
break the API later. So,
On 10/25/10 11:34 AM, Phil Steitz wrote:
On 10/25/10 11:22 AM, Steven Siebert wrote:
Phil,
I don't think we have removed the ability to access the config
options
programmatically from the config instance. You can either get a
reference
to it post-construct/build or from the getConfig() method
On Mon, Oct 25, 2010 at 12:25 PM, Phil Steitz phil.ste...@gmail.com wrote:
I notice now what I missed on initial review of Simo's patch - the pool
accessors now manage the config properties via persisted Config members. I
am OK with this, but it now means that the Config classes have to be
On 10/25/10 12:36 PM, James Carman wrote:
On Mon, Oct 25, 2010 at 12:25 PM, Phil Steitzphil.ste...@gmail.com wrote:
I notice now what I missed on initial review of Simo's patch - the pool
accessors now manage the config properties via persisted Config members. I
am OK with this, but it now
-1
At the risk of playing Devils Advocate here, what's the downside to checked
exceptions? A few extra lines of code? I can foresee a problem with
unchecked exceptions though. Imagine that you're using the API to build a
desktop application. You want to display a dialog box to the user
I agree with Mark's point about unfamiliar developers benefiting from
checked exceptions. Unlike James, I like checked exceptions =), and I have
established elegant recoveries from various resource exceptions (IO, for
example) under many use cases (at least in the enterprise arena).
What's
Very much -1 on unchecked exceptions.
On Mon, Oct 25, 2010 at 10:33 AM, James Carman
ja...@carmanconsulting.com wrote:
What do people typically do with those exceptions? Seriously, do you
retry stuff on a regular basis in your catch blocks?
Yes! Very much so. It's quite useful when dealing
On Mon, Oct 25, 2010 at 1:41 PM, Filip Defoort
filip...@cirquedigital.com wrote:
Yes! Very much so. It's quite useful when dealing with stale nfs,
locked files,...
Do you implement the retry logic in every place where you need it or
do you have a helper method that takes some sort of functor
On Mon, Oct 25, 2010 at 1:17 PM, Steven Siebert smsi...@gmail.com wrote:
I agree with Mark's point about unfamiliar developers benefiting from
checked exceptions. Unlike James, I like checked exceptions =), and I have
established elegant recoveries from various resource exceptions (IO, for
On Mon, Oct 25, 2010 at 10:45 AM, James Carman
ja...@carmanconsulting.com wrote:
On Mon, Oct 25, 2010 at 1:41 PM, Filip Defoort
filip...@cirquedigital.com wrote:
Yes! Very much so. It's quite useful when dealing with stale nfs,
locked files,...
Do you implement the retry logic in every
Checked exceptions throw a burden onto the developer. He is forced to
do something. Why force this burden? It assumes something SHOULD be
done for these particular errors. I don't think that's realistic
(they're OS errors -- not business errors), which is why checked
exceptions have fallen well
On Mon, Oct 25, 2010 at 1:48 PM, Filip Defoort
filip...@cirquedigital.com wrote:
Depends. I do have a bunch of wrappers for common types of retries,
but often the remedy really is different depending on the operation
(I'm dealing a lot with search indexes, updating them and transaction
On Mon, Oct 25, 2010 at 10:51 AM, Paul Benedict pbened...@apache.org wrote:
Checked exceptions throw a burden onto the developer. He is forced to
do something. Why force this burden? It assumes something SHOULD be
done for these particular errors. I don't think that's realistic
(they're OS
On Mon, Oct 25, 2010 at 10:52 AM, James Carman
ja...@carmanconsulting.com wrote:
On Mon, Oct 25, 2010 at 1:48 PM, Filip Defoort
filip...@cirquedigital.com wrote:
Depends. I do have a bunch of wrappers for common types of retries,
but often the remedy really is different depending on the
On Mon, Oct 25, 2010 at 1:53 PM, Filip Defoort
filip...@cirquedigital.com wrote:
In my view, it is the developer's job to provide an solid experience
to the user. That includes properly dealing with underlying system
errors in the least cryptic possible way and recovering where
possible. And
On Mon, Oct 25, 2010 at 10:56 AM, James Carman
ja...@carmanconsulting.com wrote:
On Mon, Oct 25, 2010 at 1:53 PM, Filip Defoort
filip...@cirquedigital.com wrote:
In my view, it is the developer's job to provide an solid experience
to the user. That includes properly dealing with underlying
On Mon, Oct 25, 2010 at 2:00 PM, Filip Defoort
filip...@cirquedigital.com wrote:
Well, it's my job to write proper code. Other people can do all they
want, but with just a runtime exception I wouldn't be able to do what
I'd need to do.
Again, I think you're misunderstanding my suggestion.
Le 25/10/2010 11:42, er...@apache.org a écrit :
Author: erans
Date: Mon Oct 25 09:42:33 2010
New Revision: 1027007
URL: http://svn.apache.org/viewvc?rev=1027007view=rev
Log:
MATH-428
Refactoring of DirectSearchOptimizer to separate the optimization and
simplex management aspects. Old
-Original Message-
From: Steven Siebert [mailto:smsi...@gmail.com]
Sent: Monday, October 25, 2010 08:43
To: Commons Developers List
Subject: Re: [pool] Reusing Config part 2
Gary,
I tossed this around as well, and noted these fields as a possible promote
to the Abstract
-Original Message-
From: Phil Steitz [mailto:phil.ste...@gmail.com]
Sent: Monday, October 25, 2010 08:50
To: Commons Developers List
Subject: Re: [pool] Reusing Config part 2
On 10/25/10 11:26 AM, Gary Gregory wrote:
Thank you for working through this Simone.
I would like to
-Original Message-
From: jcar...@carmanconsulting.com [mailto:jcar...@carmanconsulting.com] On
Behalf Of James Carman
Sent: Monday, October 25, 2010 08:10
To: Commons Developers List
Subject: Re: [VFS] Softening the exceptions...
On Mon, Oct 25, 2010 at 11:05 AM, Gary Gregory
On Mon, Oct 25, 2010 at 3:06 PM, Gary Gregory
ggreg...@seagullsoftware.com wrote:
So for VFS, you would prefer that all error handling be done with unchecked
exceptions?
In a nutshell, yes. So, it's a pretty easy change. You'd just change
the superclass of FileSystemException.
On Mon, Oct 25, 2010 at 3:06 PM, Gary Gregory
ggreg...@seagullsoftware.com wrote:
So for VFS, you would prefer that all error handling be done with unchecked
exceptions?
This is probably a question better asked on the user list so we can
get a feel for how people feel about it. I just
-Original Message-
From: jcar...@carmanconsulting.com [mailto:jcar...@carmanconsulting.com] On
Behalf Of James Carman
Sent: Monday, October 25, 2010 10:33
To: Commons Developers List
Subject: Re: [VFS] Softening the exceptions...
On Mon, Oct 25, 2010 at 12:49 PM, Mark Fortner
Hi!
Am 25.10.2010 um 21:13 schrieb James Carman ja...@carmanconsulting.com:
On Mon, Oct 25, 2010 at 3:06 PM, Gary Gregory
ggreg...@seagullsoftware.com wrote:
So for VFS, you would prefer that all error handling be done with unchecked
In a nutshell, yes. So, it's a pretty easy change.
On Oct 25, 2010, at 9:01 AM, James Carman wrote:
On Mon, Oct 25, 2010 at 11:49 AM, Ralph Goers
ralph.go...@dslextreme.com wrote:
I'm not in favor of changing much at this point. I'd really like to get a
release done without too many more changes.
There's a problem with that, Ralph. If
On Mon, Oct 25, 2010 at 7:44 PM, Ralph Goers ralph.go...@dslextreme.com wrote:
This code has been sitting here for a year. Commons Configuration would like
to do a release but cannot until VFS is released. I'd like to work on the VFS
release during the hackathon next week. If you believe you
The Commons Daemon team is pleased to announce the
commons-daemon-1.0.4 release!
Version 1.0.4 is primarily a bug fix release with
some new features added.
Source and binary distributions are available for download
from the Apache Commons download site:
Hi Huxing,
since the PrintStream/PrintWriter are built around an existing (open)
OutputStream/Writer: the parameter passed to the method,
it is the responsibility of the caller to close the OutputStream/Writer.
Thus, there is no need to close the PrintStream/PrintWriter (they
would close the
51 matches
Mail list logo
