+1
Costin
-Original Message-
From: Shapira, Yoav [mailto:[EMAIL PROTECTED]
Sent: 30. prosinac 2003 14:54
To: [EMAIL PROTECTED]
Subject: [Vote] Bill Barker - Commons Proper Committer
Howdy,
I think everyone knows Bill Barker already ;) He's done a
ton of work on tomcat and related
+1
Costin
Shapira, Yoav wrote:
Howdy,
The tomcat team would like to promote commons-daemon to the
commons-proper and issue a 1.0 release to serve as a dependency for
tomcat 5.0 stable.
We have been using commons-daemon for a while, and there are no open
bugs filed against it. We'll
the dependency completely - the main reason to
keep it was a backup, in case something doesn't work with the new code.
Again - digester is a great tool, but for modeler I think it is better to
use DOM.
Cotin
Thanks,
dims
--- Costin Manolache [EMAIL PROTECTED] wrote:
Craig R. McClanahan wrote
On Mon, 21 Jul 2003, Davanum Srinivas wrote:
Costin,
Right now modeler just allows parameters that are listed in the supportedType method
when we use
introspection.
#1 - How difficult/easy is it to allow other data types? (Why is this list of items
limited?)
It's not difficult to add
robert burrell donkin wrote:
(i don't want to set a president about nominating committers for
components by people who aren't committers for that component but i think
that this is a special case since folks responsible for the component have
already given a +1 before the VOTE.)
i don't
Shapira, Yoav wrote:
Hi,
I would like to propose a release of the Modeler commons component:
release 1.1. The latest version of the release notes is available here:
http://cvs.apache.org/viewcvs/jakarta-commons/modeler/RELEASE-NOTES-1.1.
txt?rev=HEADcontent-type=text/vnd.viewcvs-markup
I think modeler is now relatively stable.
It is still backward compatible with the 1.0 API - so even if a lot
of things were added/changed, I think it should be called 1.1.
I would like to build the first milestone of 1.1 and release it - so
other projects can use something stable ( tomcat5.0
+1
Costin
Stephen Colebourne wrote:
+1, and +1 on Roberts additions.
Stephen
- Original Message -
From: robert burrell donkin [EMAIL PROTECTED]
To: Jakarta Commons Developers List [EMAIL PROTECTED]
Sent: Wednesday, March 05, 2003 8:27 PM
Subject: Re: [VOTE] Release vote for
James Strachan wrote:
This pretty much reflects the current VFS architecture - the missing
piece
is
the JDNI adapter. The goal is to minimise the layering between the
providers
and the user API (be that JNDI or VFS), rather than sitting one API on
top
of
the other. I think with a bit
Nicola Ken Barozzi wrote:
Why not make Tomcat a TLP and make this a subproject?
hinthintnudgenudge
I think we are quite happy in jakarta :-)
The place for any component/library that is general purpose is (IMHO)
in jakarta-commons. However, since there is some hope that
jakarta walls will go
Nicola Ken Barozzi wrote:
They are very similar. JNDI is a little more general: a namespace of
Objects. VFS is a little more specific: a hierarchy of files.
VFS does not try to be as universal as JNDI does, even though there is
going to be plenty of overlap (find by name, create, delete,
James Strachan wrote:
From: Costin Manolache [EMAIL PROTECTED]
Hanasaki JiJi wrote:
Thinking out loud here What do you think?
1. turn the VFS providers into JNDI SPI
2. implement VFS via JNDI or the JNDI SPI's directly
+1
Tomcat abstracts the file system using JNDI - it may
Henri Yandell wrote:
On Wed, 26 Feb 2003, Costin Manolache wrote:
James Strachan wrote:
From: Costin Manolache [EMAIL PROTECTED]
It'd me nice to move the Tomcat JNDI implementation into Commons so it
can be a general purpose JNDI implementation for those that want/need
one
Juozas Baliuka wrote:
It is not my opinion about logging, but this problem exists and reported a
few times for logging and lang
(possible it nothing about this in bugzilla). Some solutionsare proposed a
few months ago too.
I have karma on commons, but as I understand I need to ask active
Shapira, Yoav wrote:
can I add myself to logging comiters list and fix this problem ?
No, you can't make yourself a committer. You are welcome to open bug
A commons committer can participate in any common component.
If you check in something and other people disagree - they can -1 it.
It
Adam Murdoch wrote:
JNDI is bundled with JDK1.3+ and is available to JDK1.1. It is well
documented ( books, etc ), required ( or strongly supported ) in Servlet
environments. I could say it is ubiquous. I can hardly see any reason
why someone would use a different API to use a VFS.
For the
Hanasaki JiJi wrote:
Thinking out loud here What do you think?
1. turn the VFS providers into JNDI SPI
2. implement VFS via JNDI or the JNDI SPI's directly
+1
Tomcat abstracts the file system using JNDI - it may be worth taking
a look. That means any JNDI based VFS would be easy to
Adam Murdoch wrote:
On Wed, 26 Feb 2003 02:17 am, Hanasaki JiJi wrote:
Any comparisons on VFS vs JNDI? seems very similar to me.
They are very similar. JNDI is a little more general: a namespace of
Objects. VFS is a little more specific: a hierarchy of files.
The namespace of Objects is
Adding 24 methods and the requirement that the logger deals with
internationalization doesn't seem right. The second part is worse -
each app uses different styles of ResourceBundles - and you mix
very different domains.
A much simpler solution - with no API change in Log - is to
use the fact
Andrew McConnell wrote:
I miss your point about different styles of ResourceBundles. Can you
elaborate?
If you pass in the key - the logger is expected to locate the bundle
and do the substitution. How do you specify where is the key stored ( which
resource bundle ) ? And AFAIK not everyone
Martin Poeschl wrote:
as the name indicates db.apache.org is for db related projects.
the db project is new but people will look for db related stuff there
and not at jakarta-commons .. so it makes sense to move the projects to
db.apache.com
And people who are already use it will look for
Eric Johnson wrote:
Hello,
I was looking into using the httpclient in an
application that requires client certificate
authentication. According to the JSSE documentation,
the mechanism for doing this is to get your
SSLSocketFactory from an SSLContext, which allows you
to specify the
Robert Leland wrote:
Costin Manolache wrote:
Martin Poeschl wrote:
as the name indicates db.apache.org is for db related projects.
the db project is new but people will look for db related stuff there
and not at jakarta-commons .. so it makes sense to move the projects to
db.apache.com
James Strachan wrote:
Maybe using introspection on the Log implementation might be easier to add
incrementally to Log implementations without breaking backwards
compatibility.
Introspection or JMX ( which is the other name for introspection :-).
Each LogFactory or Log can support a lot of
Nicola Ken Barozzi wrote:
import org.apache.commons.logging.Log;
public class SomeService {
// container sets the logger to be used using IOC
public void setLog(Log log);
}
Is that what packages using Commons Logging do?
Every single package in Commons that uses CL uses the
Ryan Hoegg wrote:
Commons-logging-api.jar is 16K, which would increase our applet JAR size
by 60+%. That's not acceptable for a system level service like logging.
You can remove the jdk14 logging and the simple logger - and jar only
the interface and a dummy factory.
Costin
Ortwin Glück wrote:
-1
Filtering can be done in most mail clients if the right subject prefixes
are used. A separate list is not necessary.
i.e. use [VOTE][Codec] and not just [VOTE]
for votes interesting for all projects you could use [VOTE][COMMONS] or
[VOTE][ALL] or similar
I
robert burrell donkin wrote:
the following concerns me about the proposal:
(4) Initial Committers
The initial committers will be identical to those of the Standard Taglib
project.
i'm unhappy with this since it implies that all current taglib committers
will be grandfathered in. a list
I have a deja-vu sentiment, I remember we already voted on this.
But +1 again.
Costin
Jan Luehe wrote:
Please cast your vote on the promotion of the commons-el package from
commons sandbox to commons proper.
The commons-el package contains the EL evaluator code from JSP 2.0.
See
robert burrell donkin wrote:
jexl is a simple expression language for accessing java objects. it is
used extensively by jelly. jexl has been (relatively) stable for a while.
jelly is pushing towards it's first release. the time therefore seems
right for jexl to be promoted to the commons.
Stefan Bodewig wrote:
On Mon, 27 Jan 2003, bob mcwhirter [EMAIL PROTECTED] wrote:
I haven't tracked ant very closely lately, but if/when it allows us
to manage ant properties external to the o.a.t.ant.Project backed by
some external structure, then grant itself will become useless.
CVS
This has been discussed in the past - but the traffic on commons is
getting bigger as we add more very active components.
We could split the list based on category - expression languages (jxpath,
jexl, jsp-el, etc ), util libraries ( logging, discovery, modeler,
collections, etc ).
Opinions ?
I wasn't planning to force anyone to move to a different list -
the reason I started this thread is that I felt overwhelmed with the
ammount of mail, and it seems commons keeps growing. I don't think it
hurts if someone asks this question every few months :-)
Given that we now have a wiki and
Rodney Waldhoff wrote:
...
Functors are a (arguably *the*) central organizing principle behind
functional programming languages like these.
And that's the reason why commons-functor needs to be aproached as a
fundamental interface, and we should require a very strong support and
Rodney Waldhoff wrote:
Try this: fill in the blanks in the following
If you want to ___, you may want to use ___.
For example:
* interact with JavaBeans via reflection and introspection; beanutils
* translate between JavaBeans and XML; betwixt
* parse command line arguments; cli
*
I don't know if you track ant-dev - I made a small change that
would allow pluggable properties. In few weeks I hope this
will stabilise ( and nobody will -1 the entire concept ).
This would provide the same features as Grant. I don't know
what is better - to depend on ant HEAD or depend on
I did few small changes to make the source of the
modeler information pluggable ( i.e. the code that reads
the xml files ). The interface is not yet final, my main
goal was to allow it to work with DOM ( for example if
we want modeler in the main loader and we don't want
all dependencies ).
It
+1
The code is already part of 2 jakarta projects ( taglibs and tomcat ), it
has a clear community and is very likely it'll be actively supported.
A perfect match for jakarta-commons.
It would be nice if JEXL and EL would share some code ( and even better
if JEXL would support the EL syntax ).
Ceki Gülcü wrote:
OK, the solution I presented solves the VOLUNTATRY separation of
logging problem. It can be further refined to address the
MANDATORY separation of logging problem Costin mentions.
Costin suggested the use of string prefixes to enforce mandatory
separation which is quite a
Craig R. McClanahan wrote:
On Wed, 11 Dec 2002, Costin Manolache wrote:
The big downsize is that we'll add a compile dependency on
JNDI ( the code can catch ClassNotFound - and run even if
JNDI is not present ).
Why couldn't we use reflection to avoid the compile-time dependency
bugfix 1.0.3 release would
be a good idea before adding making this change.
- robert
On Thursday, December 12, 2002, at 03:29 AM, Costin Manolache wrote:
Based on Ceki's email - I think it would be a good idea to add
this mechanism in the default logging factory.
My proposal is to insert
Craig R. McClanahan wrote:
I'm neutral on prefix versus suffix (although prefix feels a little more
in keeping with the hierarchical naming I tend to use for logging). But
that raises an important consideration -- do the underlying logging
implementations we support deal gracefully with a :
Ceki Gülcü wrote:
I have been a long time critic of commons-logging API for its class
loader based approach of selecting the logging implementation. See for
example my http://qos.ch/logging/thinkAgain.html document. I think
more reliable solutions exist. In particular, you might want to
Based on Ceki's email - I think it would be a good idea to add
this mechanism in the default logging factory.
My proposal is to insert a lookup for
java:comp/env/CommonsLoggingFactory
at the top of the discovery chain. If such a factory exists, it'll
be used to create the logger. If not,
robert burrell donkin wrote:
We'll not duplicate anything - the code to do what we need
already exists ( in several forms ), we'll just use it ( adapted
to the specific needs ). I don't think it'll be a problem with
the duplicated maintainance either - the code we need has been
quite stable
It would be reasonably easy to remove the deps of modeler on
digester ( use DOM or SAX directly instead ) and beanutils (
we use only a a very small piece ).
Our use of introspection will not be exposed to the user and
we have some very specific requirements ( as mandated by the spec ),
so
[EMAIL PROTECTED] wrote:
from:Jeff Robertson [EMAIL PROTECTED]
From: Rodney Waldhoff [mailto:[EMAIL PROTECTED]]
Costin If duplication is a concern - then just use
Costin beanutils ( however duplication is explicitely
Costin allowed in commons AFAIK).
Robert i've been convinced that
robert burrell donkin wrote:
the guidelines have an inbuilt mechanism whereby components may - if they
wish - prevent a new existing commons committer joining. that is, they can
veto the addition of the committers name to the list of developers for the
component.
With a valid technical
I think there are 2 separate issues.
Having one big jar with all the commons code - or one big jar
with all jakarta code - is a good idea.
So is having a distribution with 20 small jars. It's a matter
of taste, so having both is the best solution.
The issue I'm concerned with is the spaghetti
Stephen Colebourne wrote:
Jeff said:
To say (as
has been said) that this approach is not code reuse but simply copying
smacks of snobbery and is
incorrect. It is a reuse policy that allows version-freeze on small
portions of code.
Copied code is copied code. It means dual maintainance
Craig R. McClanahan wrote:
In addition to the threadClassLoader:
+1 on changing this default, by the way ... forgot to say that yesterday.
Thanks. That was the major issue.
Same for beanutils ( which is used quite extensively in digester,
and may be needed in modeler as well ).
In
Craig R. McClanahan wrote:
It doesn't quite matter. There are people using it ( digester, other
projects), it was released - we have to live with it. We may learn a
lesson about APIs and use it next time, but as long as it does what it is
supposed to do and works - you can't remove it.
I
I'm not sure I understand what is proposed :-)
However I'm strongly -1 on removing ( or deprecating ) public
code in beanutils, or on adding more dependencies.
It works fine and if another package wants to do reflection - that's
perfectly fine, but that doesn't mean everyone else is required to
Is there any reason for having 'false' for useThreadClassLoader ?
I have a number of failures with tomcat if digester is in the
parent loader, since a lot of code doesn't set this. And
IMO the correct behavior for any utility designed to work in
a server side environment is to check the thread
+1 in general. Modeler is missing several things - right now it
is 'good enough' for tomcat ( i.e. implements what we need ).
Regarding DTD extension - it is needed, however I would like to
ask you to take a look first at other DTDs that solve
the same problem ( like in jboss for example ). It
Michael Davey wrote:
Henri Yandell wrote:
I'm +1 for System.err too. Should this be institutionalised across Lang?
There has been discussion before about a 'Core' component with the bare
minimum from various commons components and upon which (nearly) every
commons component would depend.
I would like to propose 3 enhancements to modeler.
The DynamicMbean ( from tomcat-util ) can support beans that
have no xml description, using introspection. I'm in process of converting
it to a model mbean and integrate it with Registry.
The second is a new class Modeler that will act as a
Geir Magnusson Jr. wrote:
Great. Perfect description. Not disputing the general sentiment (I
still think it's moving deck chairs around if you move every committer
into the PMC).
I think it's more about a consistent naming and organization with the
rest of apache ( and the httpd project
- 8 -
Vote to promote the FileUpload component from Commons Sandbox to
Commons
Proper:
[X] +1 I am in favor of this action and will help
[ ] +0 I am in favor of this action but cannot help
[ ] -0 I am not in favor of this action
[ ] -1 I am opposed to this action and here is
Morgan Delagrange wrote:
It's correct that we did not monitor commits as
closely as we should. Roy raised our awareness or
this, and that's good. However I don't think we need
a small group to check every single commit to every
component. We all should be and will be more vigilant
now.
Morgan Delagrange wrote:
Quite right, your proposal did say all committers.
Sounds like we're essentially arguing about nothing.
I'm saying that all committers should keep an eye on
commits. You're saying that the PMC should monitor
all commits, but that the PMC should be all the
We already have a line in our charter about having a jakarta-commons
specific PMC. Right now it is modeled after jakarta, with 3
members.
I would like to propose changing this number to include more
people - I think the right solution is more closer to what httpd
and apr projects are doing,
Martin van den Bemt wrote:
Questions:
- should we vote on the volunteering offer ? What is httpd doing ?
Yes. In a way you are trusted with a task. If people think your not up
to it, they should be able to -1 it. Also a lot of +1's is good for the
ego ;)
Well, one thing I would like to
=text/vnd.viewcvs-markup
[2] http://www.plotnix.com
[3] [EMAIL PROTECTED]
Costin Manolache wrote:
The following was posted by Roy Fielding:
Just look at the commons cvs -- there is code present
that was taken from another open source project, the license removed,
and replaced
Dmitri Plotnikov wrote:
Costin,
When PLOTNIX was OFFICIALLY contributing this code to Apache, I copied
the license from some other Apache source file, which had IIRC Lotus
mentioned as the original contributor.
The original JXPath was not an Open Source project, it had an
Apache-style
Martin Cooper wrote:
I found a few things not yet mentioned:
1) In codec\Metaphone.java, Copyright 1997, William B. Brogden, which is
clearly a problem.
2) In scaffold, numerous instances of Copyright (c) 2002 Synthis
Corporation., also clearly a problem.
Acording to jakarta-commons
James Strachan wrote:
I'd really like a stable release of Jelly out ASAP so migrating it to the
commons proper sounds like a great idea.
There is no need for a stable release.
All you need ( IMO ) is a community and a plan to eventually get
a release.
Though I am having second
[EMAIL PROTECTED] wrote:
Craig R. McClanahan [EMAIL PROTECTED] wrote on 15/10/2002 02:20:01
AM:
On Mon, 14 Oct 2002 [EMAIL PROTECTED] wrote:
Is there a rule somewhere about not having sandbox components as a
dependency?
At a minimum, I think you can infer an indirect rule
I haven't used this feature - if anyone can provide a short
description and a proposal for API it'll probably have my
+1.
Regarding no-op - it may be better to try to provide a 'default'
or baseline implementation, if possible ( even if the behavior will
be inefficient ). At least IMO,
For those using gmane: I made a request for the
gmane.comp.jakarta.commons.httpclient.devel
news mirror for the new list. ( I read apache and all other lists
via news - I assume other do this too )
Costin
Jeff Dever wrote:
Hello all,
A new mailing list on Jakarta was created today for
properties
could be checked at the time that execute is called.
Again, I'm not sure what the right way to go is.
Costin Manolache wrote:
I personally thing this is a very bad idea.
There are already enough 'config' architectures:
- ant/jmx/bean style, with introspection used to call java
I personally thing this is a very bad idea.
There are already enough 'config' architectures:
- ant/jmx/bean style, with introspection used to call java bean
setters ( with or without Digester )
- jdk1.4 preferences/JNDI for hierarchical config and components
getting the info themself.
- simple
Richard Sitze wrote:
I volunteer to be the release manager.
This is also my explicit vote for cutting 1.0.2: +1
By my count, current binding votes are at:
+12 (scott sanders, richard sitze)
+00
-10
+1 as well.
As this is a majority vote ( as any release vote ) - it
FYI, on tomcat-dev we agreed ( AFAIK ) to use JNDI as the
configuration storage API, with jndi providers for the current data
source ( server.xml, jk.properties, etc ).
We'll continue to use a 2-layer config, jndi is just for storage -
normal ant-like reflection/introspection will be used to
74 matches
Mail list logo
