You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@avalon.apache.org by do...@apache.org on 2003/04/07 10:36:58 UTC
cvs commit: avalon/src/java/org/apache/avalon/framework/configuration ConfigurationUtil.java
donaldp 2003/04/07 01:36:58
Modified: src/java/org/apache/avalon/framework/configuration
ConfigurationUtil.java
Log:
Add conversion DOM to configuration
Revision Changes Path
1.14 +59 -9 avalon/src/java/org/apache/avalon/framework/configuration/ConfigurationUtil.java
Index: ConfigurationUtil.java
===================================================================
RCS file: /home/cvs/avalon/src/java/org/apache/avalon/framework/configuration/ConfigurationUtil.java,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- ConfigurationUtil.java 28 Mar 2003 19:17:32 -0000 1.13
+++ ConfigurationUtil.java 7 Apr 2003 08:36:58 -0000 1.14
@@ -52,15 +52,21 @@
* information on the Apache Software Foundation, please see
* <http://www.apache.org/>.
*/
-
package org.apache.avalon.framework.configuration;
+import java.util.ArrayList;
+import java.util.Arrays;
+import java.util.Iterator;
import javax.xml.parsers.DocumentBuilder;
import javax.xml.parsers.DocumentBuilderFactory;
import javax.xml.parsers.ParserConfigurationException;
import org.w3c.dom.Document;
import org.w3c.dom.Element;
import org.w3c.dom.Text;
+import org.w3c.dom.NamedNodeMap;
+import org.w3c.dom.Node;
+import org.w3c.dom.NodeList;
+import org.w3c.dom.CharacterData;
import java.util.ArrayList;
import java.util.Arrays;
import java.util.Iterator;
@@ -83,6 +89,52 @@
}
/**
+ * Convert a DOM Element tree into a configuration tree.
+ *
+ * @param element the DOM Element
+ * @return the configuration object
+ */
+ public static Configuration toConfiguration( final Element element )
+ {
+ final DefaultConfiguration configuration =
+ new DefaultConfiguration( element.getNodeName(), "dom-created" );
+ final NamedNodeMap attributes = element.getAttributes();
+ final int length = attributes.getLength();
+ for( int i = 0; i < length; i++ )
+ {
+ final Node node = attributes.item( i );
+ final String name = node.getNodeName();
+ final String value = node.getNodeValue();
+ configuration.setAttribute( name, value );
+ }
+
+ String content = null;
+ final NodeList nodes = element.getChildNodes();
+ final int count = nodes.getLength();
+ for( int i = 0; i < count; i++ )
+ {
+ final Node node = nodes.item( i );
+ if( node instanceof Element )
+ {
+ final Configuration child = toConfiguration( (Element)node );
+ configuration.addChild( child );
+ }
+ else if( node instanceof CharacterData )
+ {
+ final CharacterData data = (CharacterData)node;
+ content += data.getData();
+ }
+ }
+
+ if( null != content )
+ {
+ configuration.setValue( content );
+ }
+
+ return configuration;
+ }
+
+ /**
* Convert a configuration tree into a DOM Element tree.
*
* @param configuration the configuration object
@@ -123,7 +175,7 @@
{
return ser.serialize( configuration );
}
- catch (Exception e )
+ catch( Exception e )
{
return e.getMessage();
}
@@ -140,10 +192,8 @@
*/
public static boolean equals( final Configuration c1, final Configuration c2 )
{
- return c1.getName().equals( c2.getName() )
- && areValuesEqual( c1, c2 )
- && areAttributesEqual( c1, c2 )
- && areChildrenEqual( c1, c2 );
+ return c1.getName().equals( c2.getName() ) && areValuesEqual( c1, c2 ) &&
+ areAttributesEqual( c1, c2 ) && areChildrenEqual( c1, c2 );
}
/**
@@ -240,8 +290,8 @@
{
final String value1 = c1.getValue( null );
final String value2 = c2.getValue( null );
- return ( value1 == null && value2 == null )
- || ( value1 != null && value1.equals( value2 ) );
+ return ( value1 == null && value2 == null ) ||
+ ( value1 != null && value1.equals( value2 ) );
}
/**
---------------------------------------------------------------------
To unsubscribe, e-mail: cvs-unsubscribe@avalon.apache.org
For additional commands, e-mail: cvs-help@avalon.apache.org
Re: avalon-framework **Util.java
Posted by Paul Hammant <Pa...@ThoughtWorks.net>.
Leo Simons wrote:
> how much do we want the utility code in avalon-framework to grow?
> [..]
> BTW, I think the commit below makes sense; I'm just kinda wondering
> what we feel policy is...
I'm all for shrinking A-F to interfaces and directly related
ValueObjects only. My reasons for have been stated many times on the
PMC list and here: Reduction in contentious landscape, better
interface/impl separation, less bloat. Encouragement of diversity..
- Paul
--
http://www.thoughtworks.com : The art of heavy lifting.
Home for many Agile-practicing Open Source activists...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: avalon-framework **Util.java
Posted by Leo Simons <le...@apache.org>.
Peter Donald wrote:
> On Fri, 11 Apr 2003 20:11, Leo Sutic wrote:
>
>>>From: Peter Donald [mailto:peter@realityforge.org]
>>>
>>>I don't think thats worth it as most components also use the
>>>"container" util code. However I would love to see all the
>>>code that has external dependencies (on Logki/Log4j/xalan/....?)
>>>moved into a separate jar or at least have possibility of
>>>grabbing them from a separate jar.
>>
>>I was more thinking from a classloader perspective. I think some
>>people had an issue with non-interface code in the framework jar,
>>as it messed up the classloader strategy.
>
> That was me (it stops us doing a whole bunch of neat stuff in Phoenix).
> However it was not so much the separation of interface/impl - thats nice but
> largely academic and probably best to wait to AF5. What is a problem is that
> as it stands now both Log4j and Logkit (and xerces/xalan in JDK1.3)
the dep on xerces is a pain-in-da-butt!
I believe a seperation of interface/implementation jar-wise amounts to
about the same thing as moving classes with dependencies to a different jar.
Quick tests show only one slightly ugly thing (which is not an actual
issue): SAXConfigurationBuilder refers to a protected method of
AbstractConfiguration (hence needs to be in the same package). Splitting
things should be pretty clean.
- LSD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: avalon-framework **Util.java
Posted by Peter Donald <pe...@realityforge.org>.
On Fri, 11 Apr 2003 22:54, Berin Loritsch wrote:
> AFAIK, Log4J/LogKit don't need to be in the classpath--unless you are
> using the wrapper class. As long as you never load the wrapper class
> you will never have any problems. Cocoon has been using the LogKit in
> conjunction with A4 for years without problems--even though there is
> a Log4J wrapper in the JAR as well.
yep but what I want to do is use version X of LogKit/Log4j in container and
version Y in the components. I have had to help quite a few users who used
differing versions of Log4j get Phoenix setup - PITA. If they could use
whatever version they wanted and it didn't effect the container then that
would be great.
--
Cheers,
Peter Donald
---------------------------------------------------------
Clarke's Third Law: "Any technology distinguishable from
magic is insufficiently advanced".
---------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: avalon-framework **Util.java
Posted by Berin Loritsch <bl...@apache.org>.
Peter Donald wrote:
> On Fri, 11 Apr 2003 20:11, Leo Sutic wrote:
>
>>>From: Peter Donald [mailto:peter@realityforge.org]
>>>
>>>I don't think thats worth it as most components also use the
>>>"container" util code. However I would love to see all the
>>>code that has external dependencies (on Logki/Log4j/xalan/....?)
>>>moved into a separate jar or at least have possibility of
>>>grabbing them from a separate jar.
>>
>>I was more thinking from a classloader perspective. I think some
>>people had an issue with non-interface code in the framework jar,
>>as it messed up the classloader strategy.
>
>
> That was me (it stops us doing a whole bunch of neat stuff in Phoenix).
> However it was not so much the separation of interface/impl - thats nice but
> largely academic and probably best to wait to AF5. What is a problem is that
> as it stands now both Log4j and Logkit (and xerces/xalan in JDK1.3) have to
> be in the same classloader as avalon. This adds extra complexities that we
> just don't need
AFAIK, Log4J/LogKit don't need to be in the classpath--unless you are
using the wrapper class. As long as you never load the wrapper class
you will never have any problems. Cocoon has been using the LogKit in
conjunction with A4 for years without problems--even though there is
a Log4J wrapper in the JAR as well.
As to xerces/xalan, it is really the javax.xml.** support that we need.
If you have the xml-apis.jar file in your classpath, all will be well.
As long as you never use XML based configurations you will be fine.
--
"You know the world is going crazy when the best
rapper is a white guy, the best golfer is a black guy,
The Swiss hold the America's Cup, France is
accusing the US of arrogance, and Germany doesn't want
to go to war. And the 3 most powerful men in America
are named 'Bush', 'Dick', and 'Colon' (sic)".
-----Chris Rock
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: avalon-framework **Util.java
Posted by Peter Donald <pe...@realityforge.org>.
RE: 1.4 logging
Keep it in framework. All I am trying to solve is the classloader issues.
--
Cheers,
Peter Donald
*-------------------------------------------------*
| "I have never let my schooling interfere |
| with my education." -Mark Twain |
*-------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: avalon-framework **Util.java
Posted by Berin Loritsch <bl...@apache.org>.
Peter Donald wrote:
> On Tue, 15 Apr 2003 00:28, Berin Loritsch wrote:
>
>>Peter Donald wrote:
>>
>>>No comment ? Just do it?
>>
>>How do you propose doing it without breaking compatibility?
>
>
> Leave everything in framework as is. Add facades to Logkit/Log4j. After they
> are both released then we can deprecate the avalon versions. That way the
> facades evolve in lockstep with the products they are facades for. Cleans up
> our classloader story.
>
> Add in intermediate bootstrap-avalon-framework gump project to break
> dependency loop and have logkit/log4j depend on that. Then have
> avalon-framework project just include our current stuff aswell. In time the
> current stuff can simply inherit from the Logkit/Log4j facades.
And JDK 1.4 logging?
Any proposed work around for that?
--
"You know the world is going crazy when the best
rapper is a white guy, the best golfer is a black guy,
The Swiss hold the America's Cup, France is
accusing the US of arrogance, and Germany doesn't want
to go to war. And the 3 most powerful men in America
are named 'Bush', 'Dick', and 'Colon' (sic)".
-----Chris Rock
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: avalon-framework **Util.java
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> have logkit/log4j depend on that.
What is the attitude among log4j:ers to depend on AF?
I think this should be resolved first.
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: avalon-framework **Util.java
Posted by Peter Donald <pe...@realityforge.org>.
On Tue, 15 Apr 2003 00:28, Berin Loritsch wrote:
> Peter Donald wrote:
> > No comment ? Just do it?
>
> How do you propose doing it without breaking compatibility?
Leave everything in framework as is. Add facades to Logkit/Log4j. After they
are both released then we can deprecate the avalon versions. That way the
facades evolve in lockstep with the products they are facades for. Cleans up
our classloader story.
Add in intermediate bootstrap-avalon-framework gump project to break
dependency loop and have logkit/log4j depend on that. Then have
avalon-framework project just include our current stuff aswell. In time the
current stuff can simply inherit from the Logkit/Log4j facades.
--
Cheers,
Peter Donald
----------------------------------------
"Liberty means responsibility. That is
why most men dread it." - Locke
----------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: avalon-framework **Util.java
Posted by Berin Loritsch <bl...@apache.org>.
Peter Donald wrote:
> No comment ? Just do it?
How do you propose doing it without breaking compatibility?
>
> On Sat, 12 Apr 2003 08:57, Peter Donald wrote:
>
>>On Fri, 11 Apr 2003 23:24, Peter Donald wrote:
>>
>>>On Fri, 11 Apr 2003 23:08, Berin Loritsch wrote:
>>>
>>>>Peter Donald wrote:
>>>>
>>>>>maybe. I would still just go the path of separating out things that
>>>>>needed separation due to external dependencies as many of my
>>>>>components use what would be considered "impl" parts.
>>>>>
>>>>>What we could do is migrate the Logkit adapter into the Logkit
>>>>>project and ask Log4j to host the Log4j adapter. Then we are left
>>>>>with just the XML deps which disapear as a problem in JDK1.4.
>>>>
>>>>The only problem with that approach is the circular dependency.
>>>
>>>thats a short-term problem. Maybe we should look at solving this over the
>>>longer term?
>
>
--
"You know the world is going crazy when the best
rapper is a white guy, the best golfer is a black guy,
The Swiss hold the America's Cup, France is
accusing the US of arrogance, and Germany doesn't want
to go to war. And the 3 most powerful men in America
are named 'Bush', 'Dick', and 'Colon' (sic)".
-----Chris Rock
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: avalon-framework **Util.java
Posted by Leo Simons <le...@apache.org>.
Peter Donald wrote:
> No comment?
not so sure (hence silent). I am wondering what the risk/benefit ratio
is, where the benefit is AIUI small when you have a seperate interface
jar already, and the risk is in such a thing breaking something
somewhere, and it could be considerable. Surely, we'll have a circular
dependency issue for a long time as we have to keep the classes in
avalon-framework (probably as wrappers around the moved classes) as well
for compatibility.
> Just do it?
For changes like this to something as core framework, I prefer "vote
first, act later" over "just do it", as a change like this could have an
impact on quite a few projects, and a vote is a good means to draw
attention.
cheers!
- LSD
> On Sat, 12 Apr 2003 08:57, Peter Donald wrote:
>>On Fri, 11 Apr 2003 23:24, Peter Donald wrote:
>>>On Fri, 11 Apr 2003 23:08, Berin Loritsch wrote:
>>>>Peter Donald wrote:
>>>>
>>>>>maybe. I would still just go the path of separating out things that
>>>>>needed separation due to external dependencies as many of my
>>>>>components use what would be considered "impl" parts.
>>>>>
>>>>>What we could do is migrate the Logkit adapter into the Logkit
>>>>>project and ask Log4j to host the Log4j adapter. Then we are left
>>>>>with just the XML deps which disapear as a problem in JDK1.4.
>>>>
>>>>The only problem with that approach is the circular dependency.
>>>
>>>thats a short-term problem. Maybe we should look at solving this over the
>>>longer term?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: avalon-framework **Util.java
Posted by Peter Donald <pe...@realityforge.org>.
No comment ? Just do it?
On Sat, 12 Apr 2003 08:57, Peter Donald wrote:
> On Fri, 11 Apr 2003 23:24, Peter Donald wrote:
> > On Fri, 11 Apr 2003 23:08, Berin Loritsch wrote:
> > > Peter Donald wrote:
> > > > maybe. I would still just go the path of separating out things that
> > > > needed separation due to external dependencies as many of my
> > > > components use what would be considered "impl" parts.
> > > >
> > > > What we could do is migrate the Logkit adapter into the Logkit
> > > > project and ask Log4j to host the Log4j adapter. Then we are left
> > > > with just the XML deps which disapear as a problem in JDK1.4.
> > >
> > > The only problem with that approach is the circular dependency.
> >
> > thats a short-term problem. Maybe we should look at solving this over the
> > longer term?
--
Cheers,
Peter Donald
*-------------------------------------------*
| "A handful of sand is an anthology of the |
| universe." -Albert Einstein |
*-------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: avalon-framework **Util.java
Posted by Peter Donald <pe...@realityforge.org>.
On Fri, 11 Apr 2003 23:24, Peter Donald wrote:
> On Fri, 11 Apr 2003 23:08, Berin Loritsch wrote:
> > Peter Donald wrote:
> > > maybe. I would still just go the path of separating out things that
> > > needed separation due to external dependencies as many of my components
> > > use what would be considered "impl" parts.
> > >
> > > What we could do is migrate the Logkit adapter into the Logkit project
> > > and ask Log4j to host the Log4j adapter. Then we are left with just the
> > > XML deps which disapear as a problem in JDK1.4.
> >
> > The only problem with that approach is the circular dependency.
>
> thats a short-term problem. Maybe we should look at solving this over the
> longer term?
--
Cheers,
Peter Donald
*-----------------------------------------------------*
* "Faced with the choice between changing one's mind, *
* and proving that there is no need to do so - almost *
* everyone gets busy on the proof." *
* - John Kenneth Galbraith *
*-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: avalon-framework **Util.java
Posted by Peter Donald <pe...@realityforge.org>.
On Fri, 11 Apr 2003 23:08, Berin Loritsch wrote:
> Peter Donald wrote:
> > maybe. I would still just go the path of separating out things that
> > needed separation due to external dependencies as many of my components
> > use what would be considered "impl" parts.
> >
> > What we could do is migrate the Logkit adapter into the Logkit project
> > and ask Log4j to host the Log4j adapter. Then we are left with just the
> > XML deps which disapear as a problem in JDK1.4.
>
> The only problem with that approach is the circular dependency.
thats a short-term problem. Maybe we should look at solving this over the
longer term?
--
Cheers,
Peter Donald
*----------------------------------------------------*
| "Luck is the residue of design" -- Branch Rickey |
*----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: avalon-framework **Util.java
Posted by Berin Loritsch <bl...@apache.org>.
Peter Donald wrote:
>
> maybe. I would still just go the path of separating out things that needed
> separation due to external dependencies as many of my components use what
> would be considered "impl" parts.
>
> What we could do is migrate the Logkit adapter into the Logkit project and ask
> Log4j to host the Log4j adapter. Then we are left with just the XML deps
> which disapear as a problem in JDK1.4.
The only problem with that approach is the circular dependency. We have
to have the Avalon Logger interface in Avalon, and both LogKit and Log4J
would have to depend on Avalon. In the mean time, we have to keep the
deprecated versions of the classes which means we depend back on those
projects.
Its just messy.
--
"You know the world is going crazy when the best
rapper is a white guy, the best golfer is a black guy,
The Swiss hold the America's Cup, France is
accusing the US of arrogance, and Germany doesn't want
to go to war. And the 3 most powerful men in America
are named 'Bush', 'Dick', and 'Colon' (sic)".
-----Chris Rock
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: avalon-framework **Util.java
Posted by Peter Donald <pe...@realityforge.org>.
On Fri, 11 Apr 2003 21:49, Leo Sutic wrote:
> > From: Peter Donald [mailto:peter@realityforge.org]
> >
> > From memory the files that need to be factored out include;
> >
> > logger.Loggable
> > logger.AbstractLoggable
> > logger.LogKit2AvalonLoggerAdapter
> > logger.LogKitLogger
> > logger.Log4jLogger
> > configuration.ConfigurationUtil
> > configuration.DefaultConfigurationBuilder
> > configuration.DefaultConfigurationSerializer
> > configuration.NamespacedSAXConfigurationHandler
> > configuration.SAXConfigurationHandler
> >
> > And I think there was one more somewhere ... forget.
>
> Jdk14Logger (for JDK1.3)?
doesn't really matter either way. It wont work in JDK1.3 regardless of where
you put it ;)
> All of these seem to be things that would go out in an interface/impl
> separation.
maybe. I would still just go the path of separating out things that needed
separation due to external dependencies as many of my components use what
would be considered "impl" parts.
What we could do is migrate the Logkit adapter into the Logkit project and ask
Log4j to host the Log4j adapter. Then we are left with just the XML deps
which disapear as a problem in JDK1.4.
> If we keep a big jar for backwards compatibility, but
> offer interface/impl jars as an alternative, then is there any
> reason why this can't make it into next AF release?
Nope. I think it was voted on in the past but no one actually stepped up to do
the work.
--
Cheers,
Peter Donald
-----------------------------------------------------------
Don't take life too seriously --
you'll never get out of it alive.
-----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: avalon-framework **Util.java
Posted by Berin Loritsch <bl...@apache.org>.
Leo Sutic wrote:
>
>>From: Peter Donald [mailto:peter@realityforge.org]
>>
>>>From memory the files that need to be factored out include;
>>
>>logger.Loggable
>>logger.AbstractLoggable
>>logger.LogKit2AvalonLoggerAdapter
>>logger.LogKitLogger
>>logger.Log4jLogger
>>configuration.ConfigurationUtil
>>configuration.DefaultConfigurationBuilder
>>configuration.DefaultConfigurationSerializer
>>configuration.NamespacedSAXConfigurationHandler
>>configuration.SAXConfigurationHandler
>>
>>And I think there was one more somewhere ... forget.
>
>
> Jdk14Logger (for JDK1.3)?
That is not compiled in if it doesn't exist.
> All of these seem to be things that would go out in an interface/impl
> separation. If we keep a big jar for backwards compatibility, but
> offer interface/impl jars as an alternative, then is there any
> reason why this can't make it into next AF release?
+1. We will call it A4.2 if we can finish getting the attribute tags
worked out (almost there).
--
"You know the world is going crazy when the best
rapper is a white guy, the best golfer is a black guy,
The Swiss hold the America's Cup, France is
accusing the US of arrogance, and Germany doesn't want
to go to war. And the 3 most powerful men in America
are named 'Bush', 'Dick', and 'Colon' (sic)".
-----Chris Rock
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: avalon-framework **Util.java
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Peter Donald [mailto:peter@realityforge.org]
>
> From memory the files that need to be factored out include;
>
> logger.Loggable
> logger.AbstractLoggable
> logger.LogKit2AvalonLoggerAdapter
> logger.LogKitLogger
> logger.Log4jLogger
> configuration.ConfigurationUtil
> configuration.DefaultConfigurationBuilder
> configuration.DefaultConfigurationSerializer
> configuration.NamespacedSAXConfigurationHandler
> configuration.SAXConfigurationHandler
>
> And I think there was one more somewhere ... forget.
Jdk14Logger (for JDK1.3)?
All of these seem to be things that would go out in an interface/impl
separation. If we keep a big jar for backwards compatibility, but
offer interface/impl jars as an alternative, then is there any
reason why this can't make it into next AF release?
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: avalon-framework **Util.java
Posted by Peter Donald <pe...@realityforge.org>.
On Fri, 11 Apr 2003 20:39, Leo Sutic wrote:
> > From: Peter Donald [mailto:peter@realityforge.org]
> >
> > What is a problem is that
> > as it stands now both Log4j and Logkit (and xerces/xalan in
> > JDK1.3) have to be in the same classloader as avalon. This
> > adds extra complexities that we just don't need
>
> Factoring out the DefaultConfigurationBuilder/Serializer along
> with other similar classes ([Namespaced]SAXConfigurationHandler)
> should do it then, or?
>
> Is there any other places in AF where any XML code is used?
From memory the files that need to be factored out include;
logger.Loggable
logger.AbstractLoggable
logger.LogKit2AvalonLoggerAdapter
logger.LogKitLogger
logger.Log4jLogger
configuration.ConfigurationUtil
configuration.DefaultConfigurationBuilder
configuration.DefaultConfigurationSerializer
configuration.NamespacedSAXConfigurationHandler
configuration.SAXConfigurationHandler
And I think there was one more somewhere ... forget.
--
Cheers,
Peter Donald
-----------------------------------------------------------
Don't take life too seriously --
you'll never get out of it alive.
-----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: avalon-framework **Util.java
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Peter Donald [mailto:peter@realityforge.org]
>
> What is a problem is that
> as it stands now both Log4j and Logkit (and xerces/xalan in
> JDK1.3) have to be in the same classloader as avalon. This
> adds extra complexities that we just don't need
Factoring out the DefaultConfigurationBuilder/Serializer along
with other similar classes ([Namespaced]SAXConfigurationHandler)
should do it then, or?
Is there any other places in AF where any XML code is used?
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: avalon-framework **Util.java
Posted by Peter Donald <pe...@realityforge.org>.
On Fri, 11 Apr 2003 20:11, Leo Sutic wrote:
> > From: Peter Donald [mailto:peter@realityforge.org]
> >
> > I don't think thats worth it as most components also use the
> > "container" util code. However I would love to see all the
> > code that has external dependencies (on Logki/Log4j/xalan/....?)
> > moved into a separate jar or at least have possibility of
> > grabbing them from a separate jar.
>
> I was more thinking from a classloader perspective. I think some
> people had an issue with non-interface code in the framework jar,
> as it messed up the classloader strategy.
That was me (it stops us doing a whole bunch of neat stuff in Phoenix).
However it was not so much the separation of interface/impl - thats nice but
largely academic and probably best to wait to AF5. What is a problem is that
as it stands now both Log4j and Logkit (and xerces/xalan in JDK1.3) have to
be in the same classloader as avalon. This adds extra complexities that we
just don't need
--
Cheers,
Peter Donald
God is Dead -- Nietzsche
Nietzsche is Dead -- God
Nietzsche is God -- The Dead
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: avalon-framework **Util.java
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Peter Donald [mailto:peter@realityforge.org]
>
> I don't think thats worth it as most components also use the
> "container" util code. However I would love to see all the
> code that has external dependencies (on Logki/Log4j/xalan/....?)
> moved into a separate jar or at least have possibility of
> grabbing them from a separate jar.
I was more thinking from a classloader perspective. I think some
people had an issue with non-interface code in the framework jar,
as it messed up the classloader strategy.
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: avalon-framework **Util.java
Posted by Peter Donald <pe...@realityforge.org>.
On Fri, 11 Apr 2003 20:05, Leo Sutic wrote:
> > BTW, I think the commit below makes sense; I'm just kinda
> > wondering what we feel policy is...
>
> Perhaps time to set one. All util code into the impl jar.
I don't think thats worth it as most components also use the "container" util
code. However I would love to see all the code that has external dependencies
(on Logki/Log4j/xalan/....?) moved into a separate jar or at least have
possibility of grabbing them from a separate jar.
--
Cheers,
Peter Donald
------------------------------------
The two secrets to success:
1- Don't tell anyone everything.
------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: avalon-framework **Util.java
Posted by Leo Simons <le...@apache.org>.
Paul Hammant wrote:
> Peter,
>
>>> Interface/Impl separation? Might be worth doing for next release.
>>>
>>> avalon-framework.jar : All of it.
>>> avalon-framework-iface.jar : Just interfaces + Parameters.
>>> avalon-framework-impl.jar : All minus avalon-framework-iface.jar.
>>
>> +1
>
> +1
>
> -api.jar though rather than -iface.jar.
>
> I asked for this a year ago and the lot of you shot me down!
well, people change their minds I guess :D There's been a vote about it
IIRC, and IIRC its been agreed this is a good idea. We should do it
before 4.1.4.
- LSD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: avalon-framework **Util.java
Posted by Paul Hammant <Pa...@ThoughtWorks.net>.
Peter,
>> Interface/Impl separation? Might be worth doing for next release.
>>
>> avalon-framework.jar : All of it.
>> avalon-framework-iface.jar : Just interfaces + Parameters.
>> avalon-framework-impl.jar : All minus avalon-framework-iface.jar.
>
>
> +1
+1
-api.jar though rather than -iface.jar.
I asked for this a year ago and the lot of you shot me down!
> I know users would like that. I think we might be able to get away
> with not doing the impl jar. That is, have the current jar, and then
> an interface-only version.
Agreed. Especially because of package sealing.
-ph
--
http://www.thoughtworks.com : The art of heavy lifting.
Home for many Agile-practicing Open Source activists...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: avalon-framework **Util.java
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> -----Original Message-----
> From: Peter Royal [mailto:proyal@apache.org]
> Sent: den 11 april 2003 13:56
> To: Avalon Developers List
> Subject: Re: avalon-framework **Util.java
>
>
> On Friday, April 11, 2003, at 06:05 AM, Leo Sutic wrote:
> > Interface/Impl separation? Might be worth doing for next release.
> >
> > avalon-framework.jar : All of it.
> > avalon-framework-iface.jar : Just interfaces + Parameters.
> > avalon-framework-impl.jar : All minus avalon-framework-iface.jar.
>
> +1
>
> I know users would like that. I think we might be able to get
> away with
> not doing the impl jar. That is, have the current jar, and then an
> interface-only version.
Having all three should be a no-brainer, as we have to do the separation
anyway:
1. Compile the stuff.
2. Jar everything into a big jar.
3. Move the interfaces to a separate tree.
4. Jar what's left into impl jar, jar interfaces into iface jar.
5. Done.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: avalon-framework **Util.java
Posted by Peter Royal <pr...@apache.org>.
On Friday, April 11, 2003, at 06:05 AM, Leo Sutic wrote:
> Interface/Impl separation? Might be worth doing for next release.
>
> avalon-framework.jar : All of it.
> avalon-framework-iface.jar : Just interfaces + Parameters.
> avalon-framework-impl.jar : All minus avalon-framework-iface.jar.
+1
I know users would like that. I think we might be able to get away with
not doing the impl jar. That is, have the current jar, and then an
interface-only version.
-pete
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: avalon-framework **Util.java
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: news [mailto:news@main.gmane.org] On Behalf Of Leo Simons
>
> Hi peeps,
>
> how much do we want the utility code in avalon-framework to grow?
Interface/Impl separation? Might be worth doing for next release.
avalon-framework.jar : All of it.
avalon-framework-iface.jar : Just interfaces + Parameters.
avalon-framework-impl.jar : All minus avalon-framework-iface.jar.
> We have a few classes which are non-trivial implementations
> of arguments passed into the lifecycle, ie
I don't mind the existence of these. They are very useful. But
maybe they should be factored out into a separate jar.
> BTW, I think the commit below makes sense; I'm just kinda
> wondering what we feel policy is...
Perhaps time to set one. All util code into the impl jar.
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
avalon-framework **Util.java
Posted by Leo Simons <le...@apache.org>.
Hi peeps,
how much do we want the utility code in avalon-framework to grow?
We have a few classes which are non-trivial implementations of arguments
passed into the lifecycle, ie
ConsoleLogger
...
AbstractConfiguration
DefaultConfiguration
SAXConfigurationBuilder
ConfigurationUtil
...
Parameters
of these, the most complex and feature-rich is the configuration
subpackage. I guess that's because it is the only thing which is
hierarchical in nature.
BTW, I think the commit below makes sense; I'm just kinda wondering what
we feel policy is...
cheers,
- Leo
donaldp@apache.org wrote:
> donaldp 2003/04/07 01:36:58
>
> Modified: src/java/org/apache/avalon/framework/configuration
> ConfigurationUtil.java
> Log:
> Add conversion DOM to configuration
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org