I didn't get as much done last night as I had hoped
:-(. I'll let y'all know when I have the code in a
decent state.
Richard
__
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com
---
[snip]
>> Does someone want to pursue this line with Chainsaw? I think
>> we should
>> create something/prove its usefulness before requesting Apache/Jakarta
>> infrastructure changes.
>
> That's a sound approach. I wouldn't mind doing the effort for Web
> Start, but it does pose two issues:
>
>
> Well, I would imagine we could get the jnlp MIME type added
> to the conf file
> on the Jakarta Apache server...:-)
One would certainly hope it isn't too much effort for the guy's and gals.
>
> Does someone want to pursue this line with Chainsaw? I think
> we should
> create something/prove
st'
> Subject: RE: Configuration GUI Status
>
>
> > What is required to host them? Just put the jars somewhere internet
> > accessible? It has been a while since I looked at Java Web
> > Start, but it
> > didn't seem too complicated at the time.
> >
>
> What is required to host them? Just put the jars somewhere internet
> accessible? It has been a while since I looked at Java Web
> Start, but it
> didn't seem too complicated at the time.
>
> -Mark
Have to modify the MIME types on the server to add the .jnlp (Java Network
Launch Protocol), a
rch 24, 2003 3:47 PM
> To: 'Log4J Developers List'
> Subject: RE: Configuration GUI Status
>
>
> > It sounds like a good start to me. This tool is a definite sandbox
> > contender.
>
> And another candidate for Java Web Start! What's Apache's
> It sounds like a good start to me. This tool is a definite sandbox
> contender.
And another candidate for Java Web Start! What's Apache's policy on hosting
Web start apps? Are the current servers configured to host them? Is any
Jakarta project using them?
cheers,
Paul Smith
--
> I thought I'd just through out there a little status update.
> I've written
> the bulk of the "rough draft" of the configuration gui guts.
> I'm working
> on the windows right now. Unfortunately, my work situation is
> deteriorating rapidly, which is occupying a tremendous amount
> of my
At 12:24 PM 3/24/2003 -0700, [EMAIL PROTECTED] wrote:
I wanted to provide explicit ConfigPanels per appender primarily to
provide a mechanism for 3rd party/propriety code to provide a custom,
pretty gui. I've also found that generic gui's are usually harder for end
user's to understand and use th
n? Where is
the code at that does this work?
Thanks!
Richard
Ceki Gülcü <[EMAIL PROTECTED]>
03/24/2003 11:34 AM
Please respond to "Log4J Developers List"
To: "Log4J Developers List" <[EMAIL PROTECTED]>,
"Log4J Developers List" <[EMA
Hi Richard,
Here are my (very) quick comments.
At 11:11 AM 3/24/2003 -0700, [EMAIL PROTECTED] wrote:
I thought I'd just through out there a little status update. I've written
the bulk of the "rough draft" of the configuration gui guts. I'm working
on the windows right now. Unfortunately, my wo
acorn +1.
-Mark
> -Original Message-
> From: Oliver Burn [mailto:[EMAIL PROTECTED]
> Sent: Thursday, March 20, 2003 4:02 PM
> To: [EMAIL PROTECTED]
> Subject: RE: Configuration GUI
>
>
> Here are some thoughts:
>
> gardner - grows things
> aborist -
List"
To: <[EMAIL PROTECTED]>
cc:
Subject:RE: Configuration GUI
Here are some thoughts:
gardner - grows things
aborist - tree doctor
acorn - it is where logs come from
grafter - assembles logs
clogger - create configuration to generate logs to clog
The best I can come up with its log4j configurator or just configurator.
At 05:19 PM 3/20/2003 -0700, you wrote:
Alright, I guess its time to start up a brainstorming session. What
should I call this thing? I thought about playing off of "Chainsaw" and
"Log". I mean, a log file is chopped up vi
Here are some thoughts:
gardner - grows things
aborist - tree doctor
acorn - it is where logs come from
grafter - assembles logs
clogger - create configuration to generate logs to clog your env ;-)
I have a few others that are probably not appropriate.
Oliver
> "seed" as in where tree's have to
"seed" as in where tree's have to come from?
Or just Log4j Configurator
cheers,
Paul
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Friday, 21 March 2003 11:20 AM
> To: Log4J Developers List
> Subject: Configuration GUI
>
>
> Alright, I guess its time
Original Message-
> From: Richard Bair [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, February 18, 2003 10:31 AM
> To: Log4J Developers List
> Subject: RE: Configuration GUI & logging.apache.org
>
>
> Nuts.
>
> From the feedback this morning it sounds like this w
Nuts.
>From the feedback this morning it sounds like this will be an
architectural issue for the different log4x groups to sort out
together. Which brings up the next question, ETA on when
logging.apache.org will be coming around? Really, the config file thing
is really a moot point until we hav
Howdy,
>We haven't exhaustively checked this out everywhere. I'd like to see in
>a logging.apache style project that we standardize on a config file
>format (xml is more flexible, is it not?), and also, can we change
>log4j.* and log4perl.* to log.*?
>
>Thoughts?
Properties and XML files both h
ginal Message-
> From: Nicko Cadell [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, February 18, 2003 11:49 AM
> To: 'Log4J Developers List'
> Subject: RE: Configuration GUI & logging.apache.org
>
>
> FYI. Currently log4net only supports an XML config file. Also
>
FYI. Currently log4net only supports an XML config file. Also it is not 100%
compatible with the log4j config file. Some of this is due to different
terminology (e.g. using the attribute 'type' rather than 'class' to specify
the dynamically loaded object types), and some due to architectural
differ
Sorry for chiming in so late on this... but you might look to see what
progress has been made in the way of various JMX MBean consoles (MC4J for
example) Most of these use the same discussed style of introspection,
where the various JMX constructs are introspected dynamically and a UI is
re
On Thursday, February 13, 2003, at 04:23 AM, Niclas Hedhman wrote:
On Thursday 13 February 2003 03:03, robert burrell donkin wrote:
On Tuesday, February 11, 2003, at 11:35 PM, Richard Bair wrote:
BTW, Mark, I'm totally wrong. The java.beans package goes all the way
back to 1.2.2 at least.
None of the people here are official representatives of the foundation. If
you prefer a more formal statement ask the Apache board or an Apache official.
Viral is perhaps a too harsh a word. Sticky is probably more appropriate.
This is my personal opinion only, not the official position of the
Niclas, Ceki, etc.,
RE: the GPL.
>Unfortunately it is a virus.
>1. A virus lives on/in a "host", in this case a software project.
>2. It spread from one host to another over a medium or carrier, in this case
>by software dependency.
Is this an official or otherwise endorsed view of the Apache G
Niclas Hedhman wrote:
On Thursday 13 February 2003 03:03, robert burrell donkin wrote:
On Tuesday, February 11, 2003, at 11:35 PM, Richard Bair wrote:
BTW, Mark, I'm totally wrong. The java.beans package goes all the way
back to 1.2.2 at least. I think it will work well for what we are doi
On Wednesday 12 February 2003 22:30, Ceki Gülcü wrote:
> Having just looked at the LGPL more closely, it may be almost as viral as
> the GPL.
>
> See also http://marc.theaimsgroup.com/?t=10447722553&r=1&w=2
One of the issues with LGPL that I know the Apache people is "on about" is
that it is
On Thursday 13 February 2003 03:03, robert burrell donkin wrote:
> On Tuesday, February 11, 2003, at 11:35 PM, Richard Bair wrote:
>
>
>
> > BTW, Mark, I'm totally wrong. The java.beans package goes all the way
> > back to 1.2.2 at least. I think it will work well for what we are doing
> > here.
On Thursday 13 February 2003 00:32, Matt Munz wrote:
> All,
>
> Perhaps I'm dense for looking for a technological solution to an
> ideological problem, but can't this be resolved with an abstraction layer?
Java is tricky since (L)GPL didn't consider the nature of Java when it was
written/updated,
:[EMAIL PROTECTED]]
> Sent: Wednesday, February 12, 2003 12:13 PM
> To: Log4J Developers List
> Subject: RE: Configuration GUI
>
>
>
>
> At 11:55 12.02.2003 -0800, you wrote:
> > > The commons-beanutils package is great. I use it all the time.
> > >
At 11:55 12.02.2003 -0800, you wrote:
> The commons-beanutils package is great. I use it all the time.
> Unfortunately, it depends on the commons-logging API which makes it
> unsuitable for use within log4j.
Ceki, I understand why this is true for the core log4j classes, but is this
also true
> The commons-beanutils package is great. I use it all the time.
> Unfortunately, it depends on the commons-logging API which makes it
> unsuitable for use within log4j.
Ceki, I understand why this is true for the core log4j classes, but is this
also true for stand alone tools like this proposed
On Tuesday, February 11, 2003, at 11:35 PM, Richard Bair wrote:
BTW, Mark, I'm totally wrong. The java.beans package goes all the way
back to 1.2.2 at least. I think it will work well for what we are doing
here.
if you're using java 1.3 (and maybe some earlier versions), you need to be
a b
> Many parts of the java.beans package are JDK 1.4 specific other parts are
> date back to JDK 1.1. What do you need to do exactly? By the way, log4j has
> its own beans processing tools in o.a.log4j.config package. They are not as
> complete as
> commons-beanutils but they get the job done (at
riginal Message-
From: Jacob Kjome [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, February 12, 2003 10:54 AM
To: Log4J Developers List
Subject: Re: Open source licensing (was RE: Configuration GUI)
I guess I'll have to take a closer look myself and digest some of these
issues before comme
I guess I'll have to take a closer look myself and digest some of these
issues before commenting further.
thanks for the pointer to the discussion.
Jake
At 03:30 PM 2/12/2003 +0100, you wrote:
Having just looked at the LGPL more closely, it may be almost as viral as
the GPL.
See also http:/
Having just looked at the LGPL more closely, it may be almost as viral as
the GPL.
See also http://marc.theaimsgroup.com/?t=10447722553&r=1&w=2
At 08:14 12.02.2003 -0600, you wrote:
Hi Ceki,
I concur with your sentiments.
I don't know the details of Apache's dislike for the LGPL licence
Hi Ceki,
I concur with your sentiments.
I don't know the details of Apache's dislike for the LGPL licence but, on
the face of it, it seems just silly. It is obvious to anyone and everyone
what intent an author has when he/she puts their library under LGPL. It is
meant to be freely useable a
At 16:28 11.02.2003 -0700, Richard Bair wrote:
I initially tried to use beanutils for the project, and to some extent
it worked well. I just found after 3 or 4 refactorings that the stuff
that was bundled with Java was much better suited to what I was trying
to do. I can look at it again for thi
it.
>
> Regards,
> Oliver
>
> > -Original Message-
> > From: Richard Bair [mailto:[EMAIL PROTECTED]]
> > Sent: Wednesday, 12 February 2003 09:08
> > To: Log4J Developers List
> > Subject: RE: Configuration GUI
> >
> >
> > The cool thin
LOL! I think we just answered each others questions. :-)
> -Original Message-
> From: Mark Womack [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, 12 February 2003 10:36
> To: 'Log4J Developers List'
> Subject: RE: Configuration GUI
>
>
> [EMAIL PROTECT
,
Oliver
> -Original Message-
> From: Richard Bair [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, 12 February 2003 10:24
> To: Log4J Developers List
> Subject: RE: Configuration GUI
>
>
> That's good to know. Since I'm the sole author of the guibuilder code,
Ya, that's more or less how I'm doing it for my guibuilder. I tried to
stick as close to the api as possible. It allows for plugins pretty
well.
I guess I only used the PropertyEditor for editors that I was going to
call from my property sheet, but the same interface should work here as
well.
B
; -Original Message-
> From: Richard Bair [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, February 11, 2003 3:24 PM
> To: Log4J Developers List
> Subject: RE: Configuration GUI
>
>
> That's good to know. Since I'm the sole author of the
> guibuilder code,
&
> > The one drawback I see with going this route is that creating a really
> > generic tool sometimes means that the user interface isn't as
> > intuitive.
> >
> > For instance, I think it would make for a cleaner UI to
> > provide the user
> > of a FileAppender a checkbox for bufferedIO and App
> -Original Message-
> > From: Richard Bair [mailto:[EMAIL PROTECTED]]
> > Sent: Wednesday, 12 February 2003 09:08
> > To: Log4J Developers List
> > Subject: RE: Configuration GUI
> >
> >
> > The cool thing about this idea is that we'd
Richard Bair wrote:
The cool thing about this idea is that we'd be able to set properties
for any given appender without the need of a ton of custom code. I'm in
the process of building a guibuilder right now as well, so reflection
and property sheets are almost second nature ;-)
The one drawbac
of using LGPL
code, when the Log4J project may not be able to use it.
Regards,
Oliver
> -Original Message-
> From: Richard Bair [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, 12 February 2003 09:08
> To: Log4J Developers List
> Subject: RE: Configuration GUI
>
>
> T
> -Original Message-
> From: Richard Bair [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, February 11, 2003 2:13 PM
> To: Log4J Developers List
> Subject: RE: Configuration GUI
>
>
> Mark,
>
> Should I build the basic app, and then submit it to sandbox, or start
>
> The one drawback I see with going this route is that creating a really
> generic tool sometimes means that the user interface isn't as
> intuitive.
>
> For instance, I think it would make for a cleaner UI to
> provide the user
> of a FileAppender a checkbox for bufferedIO and Append, and a spi
Mark,
Should I build the basic app, and then submit it to sandbox, or start
building it there from the get-go?
Richard
On Tue, 2003-02-11 at 14:38, Mark Womack wrote:
> I'd like to see a tool that performs reflection on the various classes to
> let you know what parameters can be set. So, if I c
The cool thing about this idea is that we'd be able to set properties
for any given appender without the need of a ton of custom code. I'm in
the process of building a guibuilder right now as well, so reflection
and property sheets are almost second nature ;-)
The one drawback I see with going th
I'd like to see a tool that performs reflection on the various classes to
let you know what parameters can be set. So, if I chose to add a
FileAppender, the list of configuration options would be gathered by looking
at the property setter methods defined in that class.
I remember someone mentioni
Hi,
A random thought, but I would endeavour to keep the internal
representation of the configuration independent of the external
representation. That way it is possible to support multiple
external formats. You have mentioned XML and properties files.
I know that the Jalopy source code formatter
54 matches
Mail list logo
