You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by Curt Arnold <ca...@houston.rr.com> on 2004/12/10 20:44:56 UTC
Namespaces in configuration files
I think I briefly mentioned this
http://nagoya.apache.org/eyebrowse/ReadMsg?listName=log4j-
dev@logging.apache.org&msgNo=8220
>
> The old namespace needs to be recognized by JoranConfigurator to
> remain compatible with existing configuration files. However, it
> could also recognize an additional namespace that doesn't conceptually
> tie the document to Jakarta. However adding that new namespace would
> compel log4cxx and log4net to support it also so they could still
> trade configuration files. I wouldn't establish a new namespace until
> we've had a chance to review any differences between the
> implementations and then more explicitly define the namespace with a
> schema or similar.
Recent CVS changes
(http://nagoya.apache.org/eyebrowse/ReadMsg?listName=log4j-
dev@logging.apache.org&msgNo=8362) to some of the sample configuration
files have started using the "http://logging.apache.org" in place of
"http://jakarta.apache.org/log4j/".
I think it is a good idea that we introduce a new namespace for
configuration files, but I would not want to do it casually. We should
maintain compatibility with old configuration files that use the
"http://jakarta.apache.org/log4j/" namespace. However, we should use
the namespace break to clean up some issues.
My recommendations would be to:
Change the namespaces in the sample files back to
"http://jakarta.apache.org/log4j/"
Define a new namespace "http://logging.apache.org/configuration/" with
an accompanying XML Schema.
When the definition of the new namespace is worked out, then the test
configuration files can be changed or left as compatibility tests for
the old configuration format.
I think it would be good to use a little more specific namespace for
the configuration file than "http://logging.apache.org". By using
"http://logging.apache.org/configuration/", we clearly distinguish
between our configuration XML dialect and our log reporting dialect.
The most significant change in the document structure that I would
recommend would be to move all the log4j configuration elements into a
common namespace. In existing XML configuration files, only the
"configuration" element is in the "http://jakarta.apache.org/log4j"
namespace, all the child elements have no specified namespace. That is
legal, but not normal, practice with namespaces.
Assuming this change was made, migrating an existing XML configuration
to the new namespace would likely only take changing the configuration
element from:
<log4j:configuration xmlns:log4j="http://jakarta.apache.org/log4j/">
</log4j:configuration>
to either
<log4j:configuration
xmlns:log4j="http://logging.apache.org/configuration/"
xmlns="http://logging.apache.org/configuration/">
</log4j:configuration>
or
<configuration xmlns="http://logging.apache.org/configuration/">
</configuration>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Namespaces in configuration files
Posted by Curt Arnold <ca...@houston.rr.com>.
On Dec 10, 2004, at 2:39 PM, Ceki Gülcü wrote:
> An accompanying XML Schema? OK, how would you deal with elements
> handled by implicit rules or elements defined within the XML file
> itself?
Most likely by allowing elements or attributes from foreign namespaces
to appear anywhere in the document. So if example.com created its own
appender that had unexpected configuration information, they could just
declare their own namespace and elements and place them within
recognized log4j elements.
<appender name="foo" class="com.example.logging.FooBarAppender">
<foobar xmlns="http://logging.example.com/FooBar" greeting="Hello,
World"/>
</appender>
The current JoranDocument discards unrecognized elements, but would now
need to keep any elements and JoranInterpreter would need to be
enhanced to appropriately handle unrecognized namespaces.
It is the type of problem that namespaces were designed to handle and
does a pretty good job at. I'm pretty confident that we can work out a
reasonable approach, but I'd really need to look at the specific use
cases. I think this could be addressed after the base structure is
fleshed out.
There is a trick that you can play that would allow to make
JoranInterpreter namespace aware without changing the structure. You
can build a string representation of a qualified name by appending
local name, a colon and the namespace URI. Since colon's are not legal
characters in local names, they can serve as a delimiter between the
local name and the namespace. In the earlier example, you could
represent the qualified name of the foobar element as
"foobar:http://logging.example.com/FooBar"
>
> Probably a stupid question but I'll stick out my neck nonetheless.
> Would a schema buy us that much in terms of the user experience?
> Defining a schema seems like a major undertaking for a small gain...
>
The major advantage is imposing an explicit definition and not relying
on the implicit definition of whatever log4j does with the content.
> For instance, would a schema can facilitate building editors for log4j
> config files?
Yes. Having an available schema would allow some XML editors to
provide better guidance on document construction and identify some
configuration problems before attempted use. It would not catch
everything, like bad class names, but it could reduce trial and error
in building configuration files.
Many IDEs have some degree of XML Schema directed document construction.
>
>
>> I think it would be good to use a little more specific namespace for
>> the configuration file than "http://logging.apache.org". By using
>> "http://logging.apache.org/configuration/", we clearly distinguish
>> between our configuration XML dialect and our log reporting dialect.
>
> Distinguishing the configuration XML dialect and the log reporting
> dialect although safer seems like an overkill. Currently, there is no
> overlap between the two sets. Moreover, I can't image why you'd want
> to mix configuration elements with logging events.
>
> The 'http://logging.apache.org/' ns is easier to type and to remember.
>
> So,
>
> +1 for http://logging.apache.org/
> +0 for http://logging.apache.org/configuration/
>
> (Initially, I actually mistyped 'configuration' as 'configration'.)
Better than conflagration. Using "http://logging.apache.org/" for
configuration would not prevent us from defining other distinct
namespaces that start with "http://logging.apache.org/" as needed. In
this particular case, configuration files are typically manually
generated so giving them the easiest to remember namespace is probably
good.
>
>> The most significant change in the document structure that I would
>> recommend would be to move all the log4j configuration elements into a
>> common namespace. In existing XML configuration files, only the
>> "configuration" element is in the "http://jakarta.apache.org/log4j"
>> namespace, all the child elements have no specified namespace. That
>> is
>> legal, but not normal, practice with namespaces.
>
> +1. Your proposal is what we should have done long ago.
>
> At the time I would have expected the namespace spec. to automatically
> cascade the namespace to inner elements. My assumption was obviously
> wrong. Interestingly enough no one has peeped a word about the
> relative absurdity of the current structure until you came along. Not
> a single word. Kind of shakes one's belief in "the more eyes the
> better" mantra. But again, you are here. :-)
>
> Of course, you could also say that as long as it works no one really
> cares. Other's as well as my experience indicate that to elicit
> participation you have to leave dangling pieces for new contributors
> to pick up and improve up on. Perfections puts off participation.
>
>> Assuming this change was made, migrating an existing XML configuration
>> to the new namespace would likely only take changing the configuration
>> element from:
>>
>> <log4j:configuration xmlns:log4j="http://jakarta.apache.org/log4j/">
>> </log4j:configuration>
>>
>> to either
>>
>> <log4j:configuration
>> xmlns:log4j="http://logging.apache.org/configuration/"
>> xmlns="http://logging.apache.org/configuration/">
>> </log4j:configuration>
>>
>> or
>
> The form below is more pleasant to the eye and for the fingers.
>
>> <configuration xmlns="http://logging.apache.org/configuration/">
>> </configuration>
I agree but they should be indistinguishable to log4j.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Namespaces in configuration files
Posted by Ceki Gülcü <ce...@qos.ch>.
Excellent proposal. Comments below.
At 08:44 PM 12/10/2004, Curt Arnold wrote:
>Recent CVS changes
>(http://nagoya.apache.org/eyebrowse/ReadMsg?listName=log4j-
>dev@logging.apache.org&msgNo=8362) to some of the sample configuration
>files have started using the "http://logging.apache.org" in place of
>"http://jakarta.apache.org/log4j/".
Consider my recent commits with the "http://logging.apache.org"
namespace as a teaser to get the discussion going. It worked. :-)
>I think it is a good idea that we introduce a new namespace for
>configuration files, but I would not want to do it casually. We should
>maintain compatibility with old configuration files that use the
>"http://jakarta.apache.org/log4j/" namespace. However, we should use
>the namespace break to clean up some issues.
>
>My recommendations would be to:
>
>Change the namespaces in the sample files back to
>"http://jakarta.apache.org/log4j/"
>
>Define a new namespace "http://logging.apache.org/configuration/" with
>an accompanying XML Schema.
An accompanying XML Schema? OK, how would you deal with elements
handled by implicit rules or elements defined within the XML file
itself?
Probably a stupid question but I'll stick out my neck nonetheless.
Would a schema buy us that much in terms of the user experience?
Defining a schema seems like a major undertaking for a small gain...
For instance, would a schema can facilitate building editors for log4j
config files?
>I think it would be good to use a little more specific namespace for
>the configuration file than "http://logging.apache.org". By using
>"http://logging.apache.org/configuration/", we clearly distinguish
>between our configuration XML dialect and our log reporting dialect.
Distinguishing the configuration XML dialect and the log reporting
dialect although safer seems like an overkill. Currently, there is no
overlap between the two sets. Moreover, I can't image why you'd want
to mix configuration elements with logging events.
The 'http://logging.apache.org/' ns is easier to type and to remember.
So,
+1 for http://logging.apache.org/
+0 for http://logging.apache.org/configuration/
(Initially, I actually mistyped 'configuration' as 'configration'.)
>The most significant change in the document structure that I would
>recommend would be to move all the log4j configuration elements into a
>common namespace. In existing XML configuration files, only the
>"configuration" element is in the "http://jakarta.apache.org/log4j"
>namespace, all the child elements have no specified namespace. That is
>legal, but not normal, practice with namespaces.
+1. Your proposal is what we should have done long ago.
At the time I would have expected the namespace spec. to automatically
cascade the namespace to inner elements. My assumption was obviously
wrong. Interestingly enough no one has peeped a word about the
relative absurdity of the current structure until you came along. Not
a single word. Kind of shakes one's belief in "the more eyes the
better" mantra. But again, you are here. :-)
Of course, you could also say that as long as it works no one really
cares. Other's as well as my experience indicate that to elicit
participation you have to leave dangling pieces for new contributors
to pick up and improve up on. Perfections puts off participation.
>Assuming this change was made, migrating an existing XML configuration
>to the new namespace would likely only take changing the configuration
>element from:
>
><log4j:configuration xmlns:log4j="http://jakarta.apache.org/log4j/">
></log4j:configuration>
>
>to either
>
><log4j:configuration
>xmlns:log4j="http://logging.apache.org/configuration/"
>xmlns="http://logging.apache.org/configuration/">
></log4j:configuration>
>
>or
The form below is more pleasant to the eye and for the fingers.
><configuration xmlns="http://logging.apache.org/configuration/">
></configuration>
--
Ceki Gülcü
The complete log4j manual: http://qos.ch/log4j/
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org