Please note there are 2 important APIs you should look at - JMX and
java preferences.
My view on configuration is that JMX should be used as the main
interface for the configurable components, and something similar
with java preferences ( but useable in JDK 1.4 ) for storing/reading
the data.
+1 ( as non-commiter ).
I've looked at the code and seen it used, it is really cool. I wish
I had more time...
Costin
On Sun, 16 Jun 2002, Dmitri Plotnikov wrote:
I'd like to call for a release vote on JXPath 1.0 . It has been stable for
a while, and there are no outstanding bugs against
See also o.a.tomcat.util.IntrospectionUtils :-)
It also have a nice feature - it takes an args[], and using introspection
calls the setters, using -name value or -name, based on the method
signatures - setName( boolean ) or setName( String/int/whatever )
I personally find it very usefull - with
+1
Costin
On 14 Jun 2002, Martin van den Bemt wrote:
He didn't have 3 votes yet though ;) Unless you count his own vote too
;)
Mvgr,
Martin
On Fri, 2002-06-14 at 22:10, Geir Magnusson Jr. wrote:
On 6/14/02 4:07 PM, Martin van den Bemt [EMAIL PROTECTED] wrote:
+1 from a non dbcp
The problem: it won't work if commons-logging.jar is installed in the
parent class loader, and log4j.jar ( or another logger ) is installed in
a child loader ( like WEB-INF/lib ).
What happens:
- the factory uses the thread class loader to check if the log4j (
or any other impl. ) exists (
On Thu, 6 Jun 2002, Geir Magnusson Jr. wrote:
On 6/6/02 2:08 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Solution:
Split commons-logging.jar in commons-logging-api.jar ( only the API and
the LogFactoryImpl, no adapteer ) and commons-logging-impl.jar.
:)
If you knew that
On Thu, 6 Jun 2002, Geir Magnusson Jr. wrote:
I wanted to split out the factory impl from the api jar for other reasons,
feeling that the clean break between API and impl was good, but wondered
about the classloader implications.
Of course, I didn¹t realize it would break tomcat. I would
+1
Costin
On Tue, 4 Jun 2002 [EMAIL PROTECTED] wrote:
I would like to nominate Sean Sullivan as a committer for the Jakarta
Commons project. Sean has been active in providing patches and support the
HttpClient project over the last several months and I think he would be a
good addition to
Again, my +1.
I've seen only 2 patches from Richard on commons-logging, but
he is a commiter on axis, and I think it's important that
other apache projects that use/depend on our stuff and want
to contribute and make fixes can do that with minimal pain.
I think that's the base idea of
+1
Costin
On Fri, 24 May 2002, Arron Bates wrote:
Already a committer on the Struts project, wodering if the committers of
the commons would allow an extra hand for the project?...
Submitted a few patches commons for BeanUtils, and now would like to
contribute some handy collection
On Fri, 10 May 2002, Ceki Gülcü wrote:
The down side is that jakarta would have two actively supported digesters,
the one in commons and the one in log4j resulting in significant maintenance
effort being wasted.
I wouldn't say XmlMapper is 'actively' supported - the code is frozen, it
does
On Fri, 10 May 2002, Craig R. McClanahan wrote:
* If the app has no explicit configuration of commons-logging,
there are two subalternatives:
- If no other logging implementation has a services entry,
the factory configured by Log4J will be used.
- If there is also another
Hi,
I commited 2 small fixes - to report the right method/class if jdk1.4
is used and to pre-set a 'sane' config in log4j, if log4j.properties
is not found.
Are there any plans for the next release of commons-logging ?
Costin
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For
On Wed, 1 May 2002, Craig R. McClanahan wrote:
Craig, does the JDK 1.4-compiled-JAR work OK in a JDBC 2 (JDK 1.3)
environment?
It did in the quick-and-dirty test that I ran (which obviously did not
reference the Savepoint related methods). This is definitely worth
testing a little
On Tue, 30 Apr 2002, Geir Magnusson Jr. wrote:
one jakarta project ( with an aproved plan of release ) shouldn't
even need a vote to get into common proper and be released.
Now, suppose I didn't like that outcome, and did a logger copy with some
slight change, and called it TheLogger.
On Sun, 28 Apr 2002, Henri Yandell wrote:
Given two projects which are duplicating effort, such as Commons/Excalibur
or all the DBCP-style components, or a project such as mod_webapp/jk where
the older version is still in development, I think it is important for
there to be documentation
On Fri, 26 Apr 2002, Berin Loritsch wrote:
The user sits there and can't discern an immediate difference between the
products. mod_webapp/mod_jk is another example.
In the last case, its easy: mod_webapp is replacing mod_jk.
Where did you got this ?
Mod_webapp attempted to replace
On Fri, 5 Apr 2002, Geir Magnusson Jr. wrote:
I don't know if that's fair - because the application has setup and pushed
into the context the Log..
In the o.a.c.l model, I can't even replace the static LogFactory
Replace it with what ? The javadoc for the static LogFactory.getLog()
is
On Fri, 5 Apr 2002, Geir Magnusson Jr. wrote:
Replace it with what ? The javadoc for the static LogFactory.getLog()
is pretty clear, the method must implement what's in the doc.
My own implementation? (You know, that choice thing?)
So you're saying an API can never use static methods
On Thu, 4 Apr 2002, Richard Sitze wrote:
I don't see the value of the interface w/o framework as-per your comments
below. You CANNOT use the interface for totally generic code without
forcing a framework into the code also... SOMETHING has to attach an
implementation to the logger, via pull
-1.
The registration/discovery mechansims are essential for Logging
functionality.
Not to mention backward compatibility.
Costin
On Thu, 4 Apr 2002, Richard Sitze wrote:
OK then, let's see what happens:
I PROPOSE that the classes in commons logging be rearranged as follows:
no
On Fri, 5 Apr 2002, Nicola Ken Barozzi wrote:
Here is a short but insightful explanation of why Avalon decided to make
Logkit, and the reasons for using IOC (inversion of control) in logging:
http://marc.theaimsgroup.com/?l=xml-cocoon-devm=101014079017326w=2
Insightful ??? I hope you are
On Wed, 3 Apr 2002, Geir Magnusson Jr. wrote:
What we need is a marker interface that indicates a tool wants a logger, and
of course a method to give it the logger... I did a quick scan of the
public API, and there doesn't seem to be one.
So what I propose is to add an interface 'LogUser'
On Wed, 3 Apr 2002, Paul Hammant wrote:
Not wishing to be political, just to furnish you with info, the 'push'
model is described as 'Inversion of Control' --
http://jakarta.apache.org/avalon/framework/inversion-of-control.html
It is also described as JavaBeans, JMX, and few other
On Wed, 3 Apr 2002, Geir Magnusson Jr. wrote:
In other words, you also want a 'push' model for the logger. Curently each
component is supposed to 'pull' the logger.
Pull? From where?
Log log=LogFactory.getLog( MyObject.class )
( or by string ).
The current model used in log4j, jdk1.4,
On Wed, 3 Apr 2002, Craig R. McClanahan wrote:
public interface LogUser
{
public void setCommonsLogger(Log log)
}
I can see why some people might like to have a log setter method like this
(rather than letting the log-using component define its own log name).
What I don't
On Wed, 3 Apr 2002, Berin Loritsch wrote:
Components (in the formal sense) will always be tied to their container.
I don't know what is the 'formal sense' you are talking about,
but one of the goals of commons is to create components that are _not_
tied to a container.
The container
On Wed, 3 Apr 2002, Geir Magnusson Jr. wrote:
Why ? The lifecycle is not our problem - the interface just defines who a
component can be configured/managed from logging perspective.
I agree the concept is a bit broken, as a component could use multiple
log channels - and the interface
On Wed, 3 Apr 2002, Richard Sitze wrote:
Perhaps what we need is pointers (in both components) to the logger
supporting the other philosophy:
If you want pull, use commons logging.
If you want push and IoC, use the Avalon LogKit.
And again, DON'T propose trying to merge the two, their
On Wed, 3 Apr 2002, Geir Magnusson Jr. wrote:
On 4/3/02 2:45 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
On Wed, 3 Apr 2002, Geir Magnusson Jr. wrote:
Yes, that's true. I didn't realize that it o.a.c.l was actually a logging
framework I thought it was an interface we could
On Wed, 3 Apr 2002, Morgan Delagrange wrote:
I'm a little wary of adding an interface to commons-logging that _should
never be used_ inside of any other Commons component. If that interface
started popping up in our other components, that would be very bad, as it
would then imply/require
On Wed, 3 Apr 2002, Morgan Delagrange wrote:
Is that not also the case with Log4J and JDK 1.4?
Only the Avalon logger has a notion of IoC AFAIK. It
seems odd to be supporting IoC logging in
commons-logging, when we know that all of our other
components will not be able to utilize it.
On Wed, 3 Apr 2002, Morgan Delagrange wrote:
Please move the discussion about IoC and Avalon to avalon-dev.
I'm sorry if this is such a politically charged term for you. I'm merely
referring to the practice of externally generating a class' Log object.
Call it what you like.
The
On Wed, 3 Apr 2002, Richard Sitze wrote:
In this case Geir's proposal requires (somewhere, and I admit that we don't
care where) a supporting framework to be useful. It may be that the Avalon
And I'm saying that having setters _does not_ require any framework to be
useful.
In Axis you have
On Wed, 3 Apr 2002, Morgan Delagrange wrote:
I _am_ saying that this interface doesn't make me happy, because as soon as
we introduce it people will assert something like, Commons Component X does
not correctly implement the commons-logging component because Class Y does
not implement the
Hi,
I would like to propose a new common component, based on code used
in tomcat, avalon and other java servers to work as NT services and unix
daemons.
The initial code is based on the wrapper project at sourceforge,
and will replace ( and be merged with ) the other components
that
On Mon, 1 Apr 2002 [EMAIL PROTECTED] wrote:
Hi,
I would like to propose a new common component, based on code used
in tomcat, avalon and other java servers to work as NT services and unix
daemons.
The initial code is based on the wrapper project at sourceforge,
and will replace (
On Thu, 28 Mar 2002 [EMAIL PROTECTED] wrote:
Hello,
JDK1.2.2 is old and is not worth supporting, but the new
GCJ3.0 and J2ME (
The statement above gives me the impression that the author is working in an
environment where he can set the platform (development and/or deployment)
On Thu, 28 Mar 2002, Scott Sanders wrote:
I personally believe the artificial barrier is just that, artificial.
IMHO, an Apache committer is an Apache committer, and I think we should
modify the charter.
Shall I propose the vote on another thread?
Please do so !
Costin
--
To
On 12 Mar 2002, Andrew C. Oliver wrote:
So a little bird told me that Commons logging was basically done, but
unreleased. We'd like to use it for the Jakarta POI 1.5 release to
solve all of our logging whoas.
I believe 1.0 was released few weeks ago.
We may need a 1.1 release, some
Done ( the first one :-).
Costin
On Thu, 7 Mar 2002, Richard Sitze wrote:
Can someone either commit the following changes, or grant me commit
priviledges?
Thanks, ras
***
Richard A. Sitze[EMAIL PROTECTED]
CORBA Interoperability
On Tue, 26 Feb 2002, James Strachan wrote:
I've just committed a minor patch to the SimpleLog class that catches any
security exceptions thrown inside the class constructor (when accessing
system properties) which occur when using the commons-logging component
inside a container.
Good catch
On Fri, 22 Feb 2002, Morgan Delagrange wrote:
Maybe I'm not understanding correctly, but it sounds like your contributions
to the Daemon component are still pending. If so, I'd prefer to defer my
vote until you've contributed some work as patches for a while, as is
customary in Jakarta.
On Tue, 19 Feb 2002, Craig R. McClanahan wrote:
* Adding mechanisms to configure loggers through the Log interface.
No need for that - passing attributes to the factory should be enough
for most common needs.
In time we'll need to document whatever attribute names are used
for different
On Wed, 20 Feb 2002, dIon Gillard wrote:
I'd like to propose Marc Saegesser as a committer on HttpClient. Mark
has posted some great functional patches for HttpClient in the last week
and is an active user with great ideas for taking it forward.
Also, most of the 'usual' HttpClient
On Fri, 15 Feb 2002, Morgan Delagrange wrote:
Probably not a good idea, because at certain log levels we would be sending
DEBUG information to standard error, which would really junk up logs that
specifically divert standard error to another file. Your true error
messages would get buried
On Wed, 13 Feb 2002, Steve Downey wrote:
What I can't imagine is a component that knows about multiple logging
hierarchies. That smells an awful lot like the business of the application,
not the component. What it comes down to, is, what can a Digester pass into
the LogFactory.getInstance
On Wed, 13 Feb 2002, Scott Sanders wrote:
Is this just re-inventing logging? Why are we doing all of this?
Aren't we trying to just hide the complexity of Log4J/LogKit/JDK1.4,
while making them transparent?
Unfortunately - yes. The best solution, as I said many times ( including
the first
On Thu, 14 Feb 2002, Paulo Gaspar wrote:
What about multiple logging hierarchies?
I think the best solution is to add an explicit 'guard' or 'domain' to the
API.
We don't have to do it now - but we must make sure it is clear that
getInstance() _should_ return a local logger in a container
On Wed, 6 Feb 2002, Craig R. McClanahan wrote:
Configuration is a feature of a particular *implementation* of logging.
The implementations we wrap all have their own configuration mechanism.
So does the simple logger implementation that writes to System.out (which
uses system properties).
On Wed, 6 Feb 2002, Tim Vernum wrote:
1) The more you add the more you have to support.
If someone adds code to commons-logging to do basic
configuration, then commons has to support it.
You have to make sure it's not creating security problems.
You have to support it for any future
On Mon, 4 Feb 2002, Steve Downey wrote:
The case: you have 2 apps you want to keep isolated. Allowing one to
log into the other's log is unacceptable. Classloader tricks are not
allways possible and are extremely error prone ( and I would say -
ineffective, can be tricked ). And the
On Sat, 2 Feb 2002, Steve Downey wrote:
- security: getLogNames() and getInstance() are evil and unacceptable.
Both log4j and logkit have solutions that allow safe use in a
Could you elaborate on getInstance()? If the underlying logging packages
First, is the combination of getLogNames()
On Sun, 3 Feb 2002, Paulo Gaspar wrote:
I am already a convert. If you keep writing this kind of stuff I will
soon become an enthusiast of this line of reasoning and start preaching
to the masses too.
=;o)
Well, I'm already sorry about that... I have a lot of other things to
do, but Peter
On Sun, 3 Feb 2002, Peter Donald wrote:
You mean users can become developers by participating?
That's how open source works, Peter !
Almost all developers around here are users who choosed to participate.
Which is precisely my point - thanks for demonstrating it ;)
Choosing to
On Fri, 1 Feb 2002, Scott Sanders wrote:
+1 about eveything you said, although I think Peter added himself to the
STATUS file to make a point about the problems with the model in
general, not logging in particular.
And if a commiter logs in jakarta, removes all the files in the CVS or
breaks
On Sat, 2 Feb 2002, Peter Donald wrote:
Compare this to any other project - large or not. I have no idea on the
largest project (maybe TC?) so lets imagine it is TC. Even including all the
current active committers in TC I suspect it would be far less than Commons?
I suspect they all at
On Sat, 2 Feb 2002, Peter Donald wrote:
Separate voting rights not commit rights. Only people who show commitment to
a product should be able to have binding votes on it.
_Using_ a commons component in another jakarta project is a huge
commitment to that component. The rule is there to make
On Fri, 1 Feb 2002, Paulo Gaspar wrote:
Now, since you are also a security freak (like Peter Donald) I
have a (Devil's Advocate) question:
- What is the way to avoid that a hostile logger accesses the
objects that are passed to it?
I'll send a longer email with comments on the logger -
59 matches
Mail list logo
