Henri Yandell wrote:
On 2/27/06, Dennis Lundberg [EMAIL PROTECTED] wrote:
Alex Karasulu wrote:
Hiya,
The directory project depends on commons-daemon 1.0.1 and we had to
update the maven2 repo with a temporary pom.xml to allow our recent
release to go through. I wanted to contact
Jörg Schaible wrote:
Hi Henri,
Henri Yandell wrote on Friday, March 03, 2006 5:33 AM:
On 2/27/06, Dennis Lundberg [EMAIL PROTECTED] wrote:
Alex Karasulu wrote:
Hiya,
The directory project depends on commons-daemon 1.0.1 and we had to
update the maven2 repo with a temporary
Dennis Lundberg wrote:
Alex Karasulu wrote:
Hiya,
The directory project depends on commons-daemon 1.0.1 and we had to
update the maven2 repo with a temporary pom.xml to allow our recent
release to go through. I wanted to contact this list and make sure
the deployed pom is correct
Hiya,
The directory project depends on commons-daemon 1.0.1 and we had to
update the maven2 repo with a temporary pom.xml to allow our recent
release to go through. I wanted to contact this list and make sure the
deployed pom is correct. It is located here:
Hi all,
I tried to find a copy of the programs in the src/native/nt folder from
somewhere on the site but I could not find the procrun binaries.
I then tried to compile it myself using visual studio 2003 but for some
reason the resource files with wacked and the compile failed. It kept
Longson, Robert wrote:
Hi Alex,
I've managed to get procrun and prunmgr to compile with VC 2003.
First load the libprocrun.vcproj file and build it.
Second load the prunsrv.vcproj and prunmgr.vcproj files and build them.
I had to fix up the dependencies to get these to link but they
+1
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Go for it!
Henri Yandell wrote:
My opinion is that we should call a vote asap, and anyone who is -1's
should use the test to prove their point. While we still have the test
up.
I'd suggest a 1 week vote. Any -1 with worthy reason is enough to stop
it, but we would be aiming to come up with
Good work Oliver!
+1
Alex
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Tim O'Brien wrote:
+1 for commons-sql to db.apache.org
And, I'd be +1 for moving commons-dbutils to db.apache.org
Makes perfect sense.
Alex
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL
+1
Noel J. Bergman wrote:
6) should I just delete the /jakarta-commons-sandbox/email directory, or
leave the folder and a note pointing to the promotion? What about the
website as well? I think for [configuration] we just deleted both.
The ideal scenario would be to use cvs delete on
Henri Yandell wrote:
We've started doing Jakarta projects over to SVN, but we've been doing
the easy stuff first to get into the hang of it.
I think a pretty fair target for Jakarta is to be fully in SVN by the
end of next year;
So Henri you mean like in ~ 2006? This is really far out. Can't
://coconut.codehaus.org/
-Original Message-
From: Kris Nuttycombe [mailto:[EMAIL PROTECTED]
Sent: 22 September 2004 00:47
To: Jakarta Commons Developers List
Subject: Re: [chain] Pipeline implementation
Alex Karasulu wrote:
subscribers that share the same index have events
On Wed, 2004-09-22 at 10:33, Kris Nuttycombe wrote:
snip/
I'll try and get our code to Craig today so that people can have a
closer look at it.
Excellent. I think this can help me see more overlap as well.
Alex
-
To
]by=threadfrom=885656
Kris my response to you is inline.
On Mon, 2004-09-20 at 13:37, Kris Nuttycombe wrote:
Alex Karasulu wrote:
Hi Kris,
On Fri, 2004-09-17 at 19:29, Kris Nuttycombe wrote:
snip/
How is routing handled if you have multiple subscribers registered that
can handle
On Tue, 2004-09-21 at 19:46, Kris Nuttycombe wrote:
Alex Karasulu wrote:
subscribers that share the same index have events processed in parallel.
Also, perhaps instead of returning void StageHandler.handleEvent() could
return a boolean value that flags whether or not the event is allowed
Hi Kris,
On Fri, 2004-09-17 at 19:29, Kris Nuttycombe wrote:
snip/
The model that we've been using is that stages process data instead of
events, although one could certainly consider an event as a type of
Ahh that's interesting. We do the events and carry a payload. One of
Hi Kris,
On Fri, 2004-09-17 at 16:23, Kris Nuttycombe wrote:
Hi, Alex,
There is definitely some overlap here, and I think that there's good
potential for collaboration. Our current implementation of the pipeline
can definitely benefit from the per-stage thread pool configuration that
for one would be interested in performance
benchmarks of this monitor approach compared to C-L and to direct
logging e.g. log4j. Logging has to be a low-to-negligible performance
cost component.
Yoav Shapira
Millennium Research Informatics
-Original Message-
From: Alex Karasulu
On Fri, 2004-08-27 at 15:13, Craig McClanahan wrote:
On Fri, 27 Aug 2004 13:03:43 -0400, Alex Karasulu [EMAIL PROTECTED] wrote:
However I think this issue is one we can resolve if we generalize the
problem using monitors and event notification. Logging is just a
specific application
Henri,
Is there some mechanism in maven that we can use to help automate this?
Perhaps in the multiproject plugin which will automatically generate
javadocs with the proper cross referencing and gather the docs.
If we can find a standard way to make this happen (via a plugin) with
the maven
Mark,
Excuse me for taking so long before a reply. I've been thinking about
your recommendations a bit. There are several issues that come to mind
regarding NIO and in terms of general API use cases. I'll try to
outline these issues below in context.
snip/
so in StatefulDecoder you have
On Thu, 2004-07-01 at 17:09, Eric Dalquist wrote:
I don't see plugability as being a requirement. A streaming
encoder/decoder is a larger requirement as the data being encoded into a
This is ugly too and we still have not come up with the final verdict
yet but take a look here and let us know
Ooops looks like this only went out to Mark's address.
Alex
On Fri, 2004-07-02 at 11:19, Alex Karasulu wrote:
On Fri, 2004-07-02 at 10:49, Mark R. Diggory wrote:
Alex,
This looks very good.
Hey thanks Mark! But I still think we can do better I just don't know
how at this point
snip/
When I think about this, I come back to the Architecture used for the
JAXP Transformer Source and Result objects.
Is there some documentation on this architecture out there? Might be
good for me to look it over. BTW, although not directly related to JAXP
architecture specifically we
-
[X] +1 Go ahead and release 1.3-RC1
[ ] +0
[ ] -0
[ ] -1 Don't release 1.3-RC1, because...
-
Alex
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL
On Fri, 2004-06-11 at 08:53, Rodney Waldhoff wrote:
On Wed, 9 Jun 2004, Alex Karasulu wrote:
Is there a place where we can collect and localize utility methods and
classes used for unit testing? I have not found anything yet.
Is it even worth doing this?
If the answer
On Fri, 2004-06-11 at 08:51, Zeigermann, Oliver wrote:
I have created a concurrent package under o.a.c.test. I guess Threading and
Futures might fit there perfectly...
That's great! I only had the chance to add a dinky lil class or two but
will add more as time progresses.
Alex
contrary to as someone pointed out on this thread I think this subject
is very exciting. For my development projects I have also founded a
Sorry man I did not mean to insult those who are religious about testing
when I said it was boring. It's just not my favorite topic although I
do enjoy
On Fri, 2004-06-11 at 11:51, Rodney Waldhoff wrote:
On Fri, 11 Jun 2004, Alex Karasulu wrote:
I looked at JUX just now and saw that you have one class there called
ObjectTestCase.java. Would you rather move the stuff already put into
test to JUX or just add this class to the test project
On Thu, 2004-06-10 at 05:28, Jrg Schaible wrote:
Hi Alex,
in our project I have meanwhile also a collection of utility classes, that I
use over again in unit tests. It might be good to have a more common pool.
Great news Jrg! You put us over the top wrt my personal quota of 3
interested
Olivier, Jrg, Michael,
Sure this is just what we need I think. Let me get it setup and
mavenize it and we can just start adding our test code and organizing
it. I'll get on it right now.
Ok its done - you can checkout or update the jakarata-commons-sandbox
and a new test directory should
On Thu, 2004-06-10 at 11:36, Oliver Zeigermann wrote:
Nice, will do so ASAP. Any idea how to structure all this?
The only structure I have in mind right now is the o.a.c.test package
:-). Perhaps as we fill it with matter we'll start to see more of a
structure naturally emerge.
I got me one
On Thu, 2004-06-10 at 11:48, Oliver Zeigermann wrote:
Alex Karasulu wrote:
On Thu, 2004-06-10 at 10:29, Oliver Zeigermann wrote:
I could contribute a class called RendezvousBarrier. It is simple, but
very useful when testing stuff in concurrent szenarios and you want to
make non
AK I'll kick start a little sandbox project for common test related code
AK shared across ASF projects.
AK
AK What shall we call it? I figure 'test' is short and to the point.
Yes. But I believe we must setup some kind of guide line, what we try to
include and what not. E.g. I also have
On Thu, 2004-06-10 at 16:06, Martin van den Bemt wrote:
We probably should check for some overlap.
I have some Exception test stuff that could also come in handy.
It allows you to test classloader exceptions (except NoClassDefFound,
still have to figure that one out..). To get it into commons
Hi,
I've often found it necessary to write some of the same test code
snippets over and over again. Namely I'm referring to test cases for
private methods that use reflection as well as other common snippets of
code dealing with unit tests. Some of these snippets could have become
JUnit
-
[ X ] +1 Go ahead and release 3.1-RC1
[ ] +0
[ ] -0
[ ] -1 Don't release 3.1-RC1, because...
-
Alex
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:
[snip]
Just a thought - It might be interesting to look at the possibility of
auto-generating testcode from the annotation features of Java 1.5. Take
a look at these for some ideas:
http://www.langrsoft.com/articles/annotations2.html
+1 to Mr. Sutic
On Tue, 2004-06-08 at 01:52, Dirk Verbeeck wrote:
+1
-- Dirk
Henri Yandell wrote:
I see no reason not to have Leo as a committer and have him guide
commons-attributes to a release. So:
[ ] +1 Yep
[ ] -1 Nope
Hen
Eric,
On Mon, 2004-06-07 at 09:26, Eric Pugh wrote:
How is UGLI different from commons-logging? I don't want yet another
logging api to have to consider when writing my applications/components.
I don't think commons-logging takes into account any of the
configuration aspects associated with
From: Shapira, Yoav [EMAIL PROTECTED]
Date: 2004/05/12 Wed AM 08:45:45 EDT
To: Jakarta Commons Developers List [EMAIL PROTECTED]
Subject: RE: [beanutils] remove dependency on commons-logging
Just how many of the 50 first off will be logging? So take this
subclass
Every single one
Hi,
Sorry to step in late but has anyone considered the use of a generic
event callback interface for use in monitoring. Beanutil classes can
expose a BeanutilsMonitor interface with methods that are called by
the executing code to monitor notable events such as failures and
successful
-Original Message-
From: matthew.hawthorne [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 11, 2004 6:27 PM
To: Jakarta Commons Developers List
Subject: Re: [beanutils] remove dependency on commons-logging
Alex Karasulu wrote:
Sorry to step in late but has anyone considered
-Original Message-
From: Simon Kitching [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 11, 2004 6:29 PM
To: Jakarta Commons Developers List
Subject: RE: [beanutils] remove dependency on commons-logging
Hi Alex,
On Wed, 2004-05-12 at 09:55, Alex Karasulu wrote:
Hi,
Sorry
David,
At the risk of sounding like a broken record I'll reference another
conversation on the same topic about a week ago:
http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]
he.orgmsgNo=48051
Do you use this technique or something similar to no have
dependencies on logging jars?
Alex
Hi Steve,
-Original Message-
From: Viens, Steve [mailto:[EMAIL PROTECTED]
I've been looking through the DBCP source this morning and have noticed
several instances where System.out, System.err and printStackTrace()
have been used to write error or status messages to the console.
DBCP does not need a commons-logging dependency.
You might stuff a Null monitor that does nothing into DBCP at first
and allow others to be set by the user. Users can implement
a logging version of the monitor interface that uses commons-logging.
Alex
-Original Message-
From: Alex
JUnit TestCase naming conventions.
My apologies for wasting your time.
From: Alex Karasulu [EMAIL PROTECTED]
There are some additional things that I will probably do over the course
of
time that I listed in the commit message:
Things left to do:
==
o Rig the JUnit
Oleg,
* Initially I based my server code on NIO because one thread per
connection (most of which would stay idle most of the time) was kind of
luxury I could not afford. I after having spent a few days writing code
I came to the point where I needed to plug in SSL. To my dismay I found
out
Hi
From: Oleg Kalnichevski [mailto:[EMAIL PROTECTED]
With so many REALLY controversial changes to Java language long may be
our wait for 1.5 to be widely adopted. Java 1.5 requirement may be quite
a hindrance and may play against the project in the initial phase
Oh I got that feel too.
-Original Message-
From: Stephen Colebourne [mailto:[EMAIL PROTECTED]
I was hoping that Rodney would reply. Anyway, these sound like sensible
enhancements to [primitives]. I am willing to review the classes you add.
Thanks I tap on your shoulder once I check them in.
Hi,
I've written the Boolean equivalents for the collections we have in commons
primitives. Rather then just check them in I thought it might be proper to
ask first.
I needed a ArrayBooleanList as well as the other primitives to finish off
the set so I just created one.
Also I have built
Oooop that's all boolean (lowercase). My editor seems to be capitalizing
boolean.
-Original Message-
From: Alex Karasulu [mailto:[EMAIL PROTECTED]
Sent: Sunday, April 11, 2004 11:39 AM
To: 'Jakarta Commons Developers List'
Subject: [primitives] Permission to commit boolean
I think having pop throw an EmptyStackException is much nicer, even if
it is inconsistent with the current Digester.pop/peek.
+1
--Alex
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:
-Original Message-
From: Simon Kitching [mailto:[EMAIL PROTECTED]
I was just looking at the digester code as I was writing another
incarnation
of the digester pattern and noticed the pop() and peek() methods do not
need
to catch exceptions. It is just cheaper to check the
+0. No problems, but in the big scheme of things I suspect it won't
make any substantive difference in performance.
NP, I figured as much. I just see these sorts of things and they bother
me like imports that are not used. I just thought it would be the right
thing to ask before doing
Simon,
if (stack.isEmpty()) {
return null;
} else {
// right here some other thread could empty the stack, causing
// the following pop to throw an exception despite our
// check above
return stack.pop();
}
Yep gotcha now and I'm glad to hear that the pop and
.
Gary
-Original Message-
From: Alex Karasulu [mailto:[EMAIL PROTECTED]
Sent: Friday, March 26, 2004 11:51
To: 'Jakarta Commons Developers List'
Subject: [codec] Status of 1.3 Release
Gary,
When do you think the 1.3 release will be ready? Is there anything I
On Wed, 31 Mar 2004, Mark R. Diggory wrote:
[x] +1 yes, and I'll help
[ ] +0 yes, go for it, but I'll just watch.
[ ] -1 no way, you've got more work before you can do this.
Alex
-
To unsubscribe, e-mail: [EMAIL
-Original Message-
From: Henri Yandell [mailto:[EMAIL PROTECTED]
Sorry to get into this one late. Had too though since I'm one of those
directory folks :-).
I'm finally finding that I can get svn installed on suse and os x [it's
not without issue] and am looking forward to
+1
I thought the name confusing but never found a better alternative. Labeling
it with the Codec suffix gives it more meaning.
Alex
-Original Message-
From: Gary Gregory [mailto:[EMAIL PROTECTED]
Sent: Sunday, March 28, 2004 4:14 PM
To: Jakarta Commons Developers List
Subject:
Hi,
Sorry to get into this one late. Had too though since I'm one of those
directory folks :-).
From: Noel J. Bergman [mailto:[EMAIL PROTECTED]
Good but out of date. The subclipse web page appears to be lagging behind
its code:
-Original Message-
From: Noel J. Bergman [mailto:[EMAIL PROTECTED]
Branches and tags are lightweight copies. Alex Karasulu has been using
branches for scratch areas, and enjoying it quite a bit.
Sorry I'm rushing out the door but the branching is cake. It was
much more
Brett,
Ok let's take a breath and dive into this email :-).
-Original Message-
From: Brett Henderson [mailto:[EMAIL PROTECTED]
Perhaps our two approaches are closer in design than you suspect. I'll
talk
about ByteProducer and ByteConsumer from my implementation to illustrate
Hi,
I wanted to present something much more tangible on this subject. I
have some links to StatefulDecoder experiments and documents I have
prepared. I have factored these interfaces out of the directory
project as you may have guessed and until I move them into an experimental
branch in
Gary,
I've submitted a bugzilla patch for the changes we have discussed
with some minor enhancements. The enhancements are in the bug report
which you probably have in your in box. Here's the link to it just
in case:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27813
For the record I
Gary,
Please excuse the delayed response.
-Original Message-
From: Gary Gregory [mailto:[EMAIL PROTECTED]
-Original Message-
From: Alex Karasulu [mailto:[EMAIL PROTECTED]
Greg,
(1) The public Binary.BITS field is not used from anywhere. How is
it
generally
Hi,
-Original Message-
From: Gary Gregory [mailto:[EMAIL PROTECTED]
snip/
the question is, I think, what
visibility should these fields have? I see several views, from strict to
lax:
(1) Make the fields private, there are implementation details. Let the
unit tests duplicate
Gary,
If you feel like it and have the time, you are welcome to check out the
latest from CVS and submit a patch. Otherwise, I might get to it this
weekend.
Sure. I'll try to get to it before the weekend.
Alex
-
To
Greg,
(1) The public Binary.BITS field is not used from anywhere. How is it
generally useful, it has no Javadoc? Should we get rid of it?
I was planning on using it later when I cleaned up this class a bit.
If you're going for a release feel free to blow it away. I have not
decided yet
Greg,
Are you prepping for another release before looking into some of
these Stateful codec matters? I think you or someone else may
have mentioned it at some point but I forget.
Alex
-
To unsubscribe, e-mail: [EMAIL
Tim,
Although, I'd be just as happy if you worked in an EXPERIMENT branch
in codec proper.
Anywhere is good. I did not have a correct perception of what
commons-sandbox was for but it makes sense.
Alex
-
To unsubscribe,
Hi,
Could someone add this additional overload to the toAsciiString()
static method of the Binary. null and empty string handling was
also added to make things more forgiving.
The patch has an additional test case for the overload as well.
Alex
Wooops forgot the patch! So here it is.
-Original Message-
From: Alex Karasulu [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 11, 2004 12:36 PM
To: 'Jakarta Commons Developers List'
Subject: [codec][PATCH] Added overload to Binary.toAsciiString()
Hi,
Could someone add
Brett,
It will take me some time to process your last email. Just a heads up in case a
response takes a while.
Alex
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Tim, Ryan,
-Original Message-
From: Tim O'Brien [mailto:[EMAIL PROTECTED]
Good, more consensus from a user - I will commit if no one beats me to it.
Ryan Hoegg wrote:
As a user of codec, I would like to post a non-binding +1 for the
interfaces in Alex's JIRA issue. They are
Noel,
We'll get there over time I'm sure and I need to look at some of the
recommended reading that you have suggested as well. For the time being if
some people can make suggestions on how these interfaces can be altered for
the better we can begin having an open discussion around them.
Alex
Yeah looking at it now - my mailbox is a bit out of control today sorry.
-Original Message-
From: Noel J. Bergman [mailto:[EMAIL PROTECTED]
Sent: Monday, March 08, 2004 2:06 AM
To: Jakarta Commons Developers List
Subject: RE: [codec] StatefulDecoders
For the time being if some
Noel,
This will keep me busy for a while and thanks for taking the time to
respond. Please bear with me as I try to understand your view point.
Alex
-Original Message-
From: Noel J. Bergman [mailto:[EMAIL PROTECTED]
Sent: Sunday, March 07, 2004 11:25 PM
To: Jakarta Commons
From: Noel J. Bergman [EMAIL PROTECTED]
There has been some good ideas coming around [configuration] lately, I'd
like to suggest a roadmap to sort what needs to be done before the 1.0
release and what could be added later
The Directory project, home of JNDI/LDAP code, would be interested
Assignee: Alex Karasulu
Reporter: Alex Karasulu
Created: Fri, 20 Feb 2004 8:36 PM
Updated: Wed, 3 Mar 2004 9:14 PM
Due: Fri, 20 Feb 2004 12:00 AM
Description:
Submit the StatefulDecoder interface to commons-codec
/src/java/org/apache/eve/decoder/DecoderManager.java?
content-type=text%2Fplainrev=6991root=Apache-SVN
I know this stuff is not much but I want to make sure we get these
interfaces (contracts) down pat.
Alex
-Original Message-
From: Alex Karasulu [mailto:[EMAIL PROTECTED]
Sent: Thursday
Ok I'm still playing around with decoders that better match the needs of NIO
based servers which need a small preferably fixed constant size decode
footprint.
Hi,
Attached are interfaces for a stateful decoder and its helper callback
Interface. For the discussion I have the stripped down
shall try to post as much as possible today on the matter.
Please bear with me I have a formidable amount of email after a week.
Expect more from me shortly.
Respectfully,
Alex Karasulu
-
To unsubscribe, e-mail: [EMAIL PROTECTED
Hi,
Let's take the simplest topic first which is the Exception issue.
From: Tim O'Brien [mailto:[EMAIL PROTECTED]
I think the introduction of EncoderException and DecoderException in and
of itself was a mistake in the first place. Creating hierarchies of
exception just for the hell of
From: Tim O'Brien [mailto:[EMAIL PROTECTED]
Alex Karasulu wrote:
Hi,
I've been working on the idea of stateful Decoders designed for use with
non-blocking reads where buffers are read from channels and used by
decoders. As you know you don't always get the complete PDU in a single
Hi,
Noel's description is correct. Please see my additional comments below:
-Original Message-
From: Noel J. Bergman [mailto:[EMAIL PROTECTED]
How does your proposal contrast/differs/combines with what has
been referred to on this list as streamable codecs?
See
Hi,
-Original Message-
From: Gary Gregory [mailto:[EMAIL PROTECTED]
public java.util.List operation(java.nio.ByteBuffer buffer);
This brings up an interesting issue: How do we potentially package and
deliver some code that depends on Java 1.4. In a second [codec] jar? I
think
Noel,
You have some very interesting ideas here which I need to process
and consider in depth. Expect more interfaces for discussion soon.
From: Noel J. Bergman [EMAIL PROTECTED]
Date: 2004/02/25 Wed PM 03:27:43 EST
To: Jakarta Commons Developers List [EMAIL PROTECTED]
Subject: RE:
Hi,
I've been working on the idea of stateful Decoders designed for use with
non-blocking reads where buffers are read from channels and used by
decoders. As you know you don't always get the complete PDU in a single
channel read and so buffers need to be handled in a decoding session.
This
Hello,
This little class efficiently (I hope) translates binary
data into an String of ASCII '0' and '1' characters. It
uses the codec encoder/decoder interfaces. Since it's a
class addition I just jar'ed up the class and its test
case. The jar is attached and contains:
92 matches
Mail list logo
