You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Berin Loritsch <bl...@apache.org> on 2001/09/20 20:00:59 UTC
[RT] Schema & Namespace Aware Configuration
Due to my exposure to Web Services and the various XML standards,
I have been toying with the concept of a configuration standard
that would provide a rich configuration environment.
The delimna is that we need to provide a solution that is:
* Easy to use
* Provides minimal impact on the current API
* Satisfies a need
* Easily extendable
We currently have two easy to use configuration methodologies:
Configuration and Parameters. We have already discussed that
Parameters' inherently flat design works in some environments
very easily. The Configuration object provides a simple
hierarchical object that tracks hierarchical information well.
Both are simple, satisfies most needs, and already exist in
the API. They are not extendable--but that is by design.
The Configuration object's use can be further helped by the
following additional information: Namespace and Qualified name.
The Configuration object specifies the method getLocation().
It's use is not well documented, so it can be purposed to record
the namespace. The name of the component would be bound to
the local name in the XML. The last remaining issue is the
prefix or qName. Because the prefix is not as important as
the local name or the namespace, a new accessor method can be
provided called "getExtendedName()". It would work like this:
<datasource:jdbc
xmlns:datasource="resource://org/apache/avalon/excalibur/datasource/schema.xsd">
</datasource:jdbc>
conf.getName() == "jdbc"
conf.getLocation() == "resource://org/apache/avalon/excalibur/datasource/schema.xsd"
conf.getExtendedName() == "datasource:jdbc"
This does not interfere with the current API, and only provides
one additional method. What it does allow is the ability to use
industry standards for configuration (WSDL, WSDD, etc.) and to
take advantage of dynamic validation of our configuration schemas.
XML parsers can read the configuration information and validate
the file based on the various schemas, throwing exceptions when
the configuration is invalid.
The Schema approach further strengthens the contract of the Configuration
heirarchy, and takes advantage of modern parsers abilities. In fact,
it helps autodiscovery of the necessary class names by allowing the
Parser to provide the class name and role name for you. It does add
responsibility to the Component developer to provide a current schema.
Understandably, this can be construed as being too XML specific. I have
also been toying with the idea of Configuration providers. Basically,
you would have the ConfigurationBuilder.getInstance("XML") that would
be used to derive the configuration tree from an XML input stream. I
have come to the conclusion that certain sources are better suited for
different Configuration providers. For instance, XML is naturally
hierarchical and works best with Configuration elements. However,
SQL data is naturally flat and works best with Parameters elements.
Not everything can be expressed in the same way equally well--no matter
how easy it is to manipulate in program space.
Each persistence mechanism must follow its own rules. However, it is
conceivable to convert your persisted data into XML which is then able
to be handled in the expected manner. This reduces the amount of learning
curve, hides the details of the persistence mechanism, and allows you
to focus on the task at hand.
It also allows for new tools to be developed. Tools are used to augment
the development process, the configuration process, or the deployment
process. Tools are not used directly in the run-time system--so they
should not be part of any of our existing projects.
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [RT] Schema & Namespace Aware Configuration
Posted by Peter Donald <do...@apache.org>.
On Fri, 21 Sep 2001 22:54, Berin Loritsch wrote:
> > > The Configuration object's use can be further helped by the
> > > following additional information: Namespace and Qualified name.
> > > The Configuration object specifies the method getLocation().
> > > It's use is not well documented, so it can be purposed to record
> > > the namespace.
> >
> > *cough* - I use it in a lot of my proggies to specify where an error
> > occured as do some of the exception reporting in core Avalon. It allows
> > us to give meaningful error messages (ie "Missing attribute foo at
> > myconfig.xml:20").
>
> Ok.
>
> > > The name of the component would be bound to
> > > the local name in the XML. The last remaining issue is the
> > > prefix or qName. Because the prefix is not as important as
> > > the local name or the namespace, a new accessor method can be
> > > provided called "getExtendedName()". It would work like this:
> >
> > If we were to go down this path I would possibly prefer something like
> >
> > getNamespace()
> > class Namespace
> > {
> > String prefix;
> > String uri;
> > }
>
> Then if we go down that path, I would like to see something like this:
>
> getXMLName()
>
> class XMLName
> {
> String getLocalName();
> String getNamespace();
> String getQualifiedName();
> }
I think I still like Namespace class. The reason is simplicity. ie
getXMLName().getLocalName() == getName()
getXMLName().getNamespace() == getNamespace().getUri()
getXMLName().getQualifiedName() ==
getName() + ":" + getNamespace().getPrefix()
And because all the "namespace" information is in one object (namely
Namespace) that could be shared through-out configuration tree.
> This is true--but the applications that use industry standard
> configurations need to see the namespaces. That does mandate changes.
Could you give some examples. The question is are these inputs
"Configuration" or just plain input data. If they are the second then
wouldn't it be better to use JDom (or dom4j or whatever happens to be your
poison).
> > The argument goes that all configuration for a single object will always
> > be in one namespace. Thus it is up to the container to do validation et
> > al. The reason I wanted Namespace recorded in Configuration was when we
> > had hierarchial Configurations. ie Component A contains B which contains
> > C. If config for A also contains config for B (and then C) then we would
> > namespace separation.
> >
> > However as it stands that was identified as a bad pattern because you
> > could never fully validate C (or B) without initializing A. And
> > considering initialization of A comes after validation of As
> > configuration we had a problem.
> >
> > So what do you think of that ?
>
> So your saying if we divide B over C we would come up with the theta of A?
No idea what that means. The last time this conversation came up the only
case where it was determined that namespaces were needed for configuration
was when we contained configuration for a hierarchy of components in same
file.
ie It would be needed for a case like including block + mailet configuration
data in one file (like james does currently). The mailet config needs to be
in different namespace if we want to validate configuration easily. However
we later concluded that it was not possible to validate the mailet
configuration (that was contained in the block configuration) until the block
had been initialized. Because the blocks configuration is validated before
the block is initialized we could not validate the mailet at the same time
(and hence why we needed Namespaces so we could validate that separately).
However we then concluded that the mailet configuration data should not be
included in blocks configuration but in another file and the same for any
hierarchy of components. Thus the need for Namespace for *configuration* data
evaporated.
I think that was how it went ;) - It should all be in mailing list archives
somewhere though.
> WSDL declares information for how to contact a specific SOAP target. As
> such it requires you to embed Schema information as well as other
> information that must be namespaced. Working directly with SAX is
> inconvenient, and DOM is expensive. Both of them do not offer type-safe
> accessors. Hense all the benefits of our Configuration object.
This doesn't sound like configuration data per-se and I may be inclined to
use another solution .. not sure. Could you give an example?
--
Cheers,
Pete
--------------------------------------------------
The fact that nobody understands you doesn't
mean you're an artist.
--------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [RT] Schema & Namespace Aware Configuration
Posted by Berin Loritsch <bl...@apache.org>.
Peter Donald wrote:
>
> Hi,
>
> This sounds familiar - was it you or Fede who said we would never need
> Namespace info last time ? ;)
It might have been Fede...
> > The Configuration object's use can be further helped by the
> > following additional information: Namespace and Qualified name.
> > The Configuration object specifies the method getLocation().
> > It's use is not well documented, so it can be purposed to record
> > the namespace.
>
> *cough* - I use it in a lot of my proggies to specify where an error occured
> as do some of the exception reporting in core Avalon. It allows us to give
> meaningful error messages (ie "Missing attribute foo at myconfig.xml:20").
Ok.
> > The name of the component would be bound to
> > the local name in the XML. The last remaining issue is the
> > prefix or qName. Because the prefix is not as important as
> > the local name or the namespace, a new accessor method can be
> > provided called "getExtendedName()". It would work like this:
>
> If we were to go down this path I would possibly prefer something like
>
> getNamespace()
> class Namespace
> {
> String prefix;
> String uri;
> }
Then if we go down that path, I would like to see something like this:
getXMLName()
class XMLName
{
String getLocalName();
String getNamespace();
String getQualifiedName();
}
> > This does not interfere with the current API, and only provides
> > one additional method. What it does allow is the ability to use
> > industry standards for configuration (WSDL, WSDD, etc.) and to
> > take advantage of dynamic validation of our configuration schemas.
> > XML parsers can read the configuration information and validate
> > the file based on the various schemas, throwing exceptions when
> > the configuration is invalid.
>
> They can still do that at the moment without any support from Configuration
> object. So Schema/DTD is good but doesn't madate changes in Configuration
> object.
This is true--but the applications that use industry standard configurations
need to see the namespaces. That does mandate changes.
> The argument goes that all configuration for a single object will always be
> in one namespace. Thus it is up to the container to do validation et al. The
> reason I wanted Namespace recorded in Configuration was when we had
> hierarchial Configurations. ie Component A contains B which contains C. If
> config for A also contains config for B (and then C) then we would namespace
> separation.
>
> However as it stands that was identified as a bad pattern because you could
> never fully validate C (or B) without initializing A. And considering
> initialization of A comes after validation of As configuration we had a
> problem.
>
> So what do you think of that ?
So your saying if we divide B over C we would come up with the theta of A?
You lost me there.
WSDL declares information for how to contact a specific SOAP target. As such
it requires you to embed Schema information as well as other information that
must be namespaced. Working directly with SAX is inconvenient, and DOM is
expensive. Both of them do not offer type-safe accessors. Hense all the benefits
of our Configuration object.
> > Each persistence mechanism must follow its own rules. However, it is
> > conceivable to convert your persisted data into XML which is then able
> > to be handled in the expected manner. This reduces the amount of learning
> > curve, hides the details of the persistence mechanism, and allows you
> > to focus on the task at hand.
>
> Thats what I was planning on doing (when I got around to it). ie DB/LDAP/XML
> to SAX, SAX to Configuration object (and vice versa).
We have vice versa now! We just don't have DB/LDAP yet.
> > It also allows for new tools to be developed. Tools are used to augment
> > the development process, the configuration process, or the deployment
> > process. Tools are not used directly in the run-time system--so they
> > should not be part of any of our existing projects.
>
> Agreed. As a sidenote has anyone looked at Merlot (opensource XML editor). It
> looked good last time I looked at it however it only allowed structure
> specified through a DTD (not XSchema). I was wondering if there is any
> alternatives out there?
A long time ago. It proved to be unweildy then--I don't know how it is faring
now.
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Implementing the dream...
Posted by Peter Donald <do...@apache.org>.
On Tue, 25 Sep 2001 01:06, Vassilis Rizopoulos wrote:
> >sounds interesting. (and go with Velocity unless you need to learn JSP or
> >something).
>
> Already made up my mind about that and I'm going with Velocity. I already
> know JSP and it doesn't let me isolate my logic as good as Velocity
> promises - and I think it will deliver.
Yup. I wanted to use Velocity (or WebMacro or FreeMarker or other templating
engines) for ages but haven't been in a Web job where I could legitimately
take the time to learn it ;/
> Maybe not, because there is an interesting discussion springing
> from the plugability of the design - using a ComponentSelector to choose
> between page renderers and search engines can expand a wiki almost without
> limit (again defeating the keep it simple and to the point ideas inherent
> in Wiki - never at the usage level, but at the inner workings level for
> sure :) ).
;)
> Since I'm
> documenting this (design choices, code examples etc.) maybe you could use
> it as an example too (It still needs a lot of work, but it's a shame to
> waste so many bytes of notes).
documentation is good. So if you are willing to provide I am sure none will
complain ;)
> One more point I stumbled on:
> AbstractLoggable is there to help make Loggable components. Is there a
> certain reason it doesn't implement the Component interface so that
> deriving classes don't have to explicity define it themeselves? (It took me
> about 15 minutes to trace the ClassCastExceptions from this thing - I guess
> I'm not thinking quickly anymore :)) ). V.-
When AbstractLKoggable was originally added to CVS it did extend Component.
However it was later decided that it was better to be indepent of component.*
package. Mainly as each of the packages are independent of each other (ie
logger independent of activity/context/config/component/etc).
--
Cheers,
Pete
------------------------------------------------------------
militant agnostic: i don't know, and you don't know either.
------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Implementing the dream...
Posted by Vassilis Rizopoulos <va...@zuehlke.com>.
>sounds interesting. (and go with Velocity unless you need to learn JSP or
>something).
Already made up my mind about that and I'm going with Velocity. I already know JSP and it doesn't let me isolate my logic as good as Velocity promises - and I think it will deliver. With JSP I have a problem with the lifecycle of a single bean used by the JSP (with the include:bean directive) and Velocity will let me use a servlet with a slightly more complex lifecycle control (init() etc.) as a container. Although the whole nightmare infrastructure resulting from this solution slightly defeats the Wiki idea :))(Apache + Tomcat + Velocity + Excalibur - a good integration exercise). Maybe not, because there is an interesting discussion springing from the plugability of the design - using a ComponentSelector to choose between page renderers and search engines can expand a wiki almost without limit (again defeating the keep it simple and to the point ideas inherent in Wiki - never at the usage level, but at the inner workings level for sure :) ).
>> DefaultConfigurationBuilder builder = new
>> DefaultConfigurationBuilder(); Configuration sysConfig =
>> builder.buildFromFile("E:/development/wiki/src/conf/avalon-wiki.xml");
>> Configuration roleConfig =
>> builder.buildFromFile("E:/development/wiki/src/conf/roles.xml");
>> RoleManager roles = new DefaultRoleManager();
>
>replace above with
>
>DefaultRoleManager roles = new DefaultRoleManager();
>
>and the below should work
>
>> roles.configure(roleConfig);
Well, it was a case of staring at the tree and missing the forest or rather blindly following documentation without thinking :)). Did exactly this and went further to find and correct my other mistakes :)))
Since I'm documenting this (design choices, code examples etc.) maybe you could use it as an example too (It still needs a lot of work, but it's a shame to waste so many bytes of notes).
One more point I stumbled on:
AbstractLoggable is there to help make Loggable components. Is there a certain reason it doesn't implement the Component interface so that deriving classes don't have to explicity define it themeselves? (It took me about 15 minutes to trace the ClassCastExceptions from this thing - I guess I'm not thinking quickly anymore :)) ).
V.-
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Implementing the dream...
Posted by Peter Donald <do...@apache.org>.
On Fri, 21 Sep 2001 22:02, Vassilis Rizopoulos wrote:
> OK, I got wind of Avalon only a short while ago (after an extended period
> of holidays devoid of electronic interference I returned and found ASF
> piling up the new and interesting stuff) and I liked it a lot I should
> say.So I started reading and then I wanted something to implement the ideas
> and API on so...I ported Wiki as a set of components. Don't even begin to
> ask why, it's one of those X-file type things. My idea was to have the
> entry point as a servlet (or a JSP page - JSP works good as a template for
> those familiar with the inner workings of Wiki - But now I found out about
> Velocity, and that looks better)
sounds interesting. (and go with Velocity unless you need to learn JSP or
something).
> and the whole functionality on a set of
> Avalon components (so, that would be a Block, no? )
Naah Blocks are only things that exist inside the Phoenix kernel
>i.e. request processor,
> page renderer, search engine, page storage. Now, the whole concept goes
> like this:
sounds good.
> I have a JSP page that loads a bean. That bean will serve as the container
> for my service, meaning it will instantiate any components, manage their
> lifecycle etc (can I do that AND use a component manager?). I wrote this
> (keeping the 'Development...' document close at hand)
>
> DefaultConfigurationBuilder builder = new
> DefaultConfigurationBuilder(); Configuration sysConfig =
> builder.buildFromFile("E:/development/wiki/src/conf/avalon-wiki.xml");
> Configuration roleConfig =
> builder.buildFromFile("E:/development/wiki/src/conf/roles.xml");
> RoleManager roles = new DefaultRoleManager();
replace above with
DefaultRoleManager roles = new DefaultRoleManager();
and the below should work
> roles.configure(roleConfig);
--
Cheers,
Pete
----------------------------------------------------
"The only way to discover the limits of the possible
is to go beyond them into the impossible."
-Arthur C. Clarke
----------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Implementing the dream...
Posted by Vassilis Rizopoulos <va...@zuehlke.com>.
OK, I got wind of Avalon only a short while ago (after an extended period of holidays devoid of electronic interference I returned and found ASF piling up the new and interesting stuff) and I liked it a lot I should say.So I started reading and then I wanted something to implement the ideas and API on so...I ported Wiki as a set of components. Don't even begin to ask why, it's one of those X-file type things.
My idea was to have the entry point as a servlet (or a JSP page - JSP works good as a template for those familiar with the inner workings of Wiki - But now I found out about Velocity, and that looks better) and the whole functionality on a set of Avalon components (so, that would be a Block, no? ) i.e. request processor, page renderer, search engine, page storage.
Now, the whole concept goes like this:
I have a JSP page that loads a bean. That bean will serve as the container for my service, meaning it will instantiate any components, manage their lifecycle etc (can I do that AND use a component manager?).
I wrote this (keeping the 'Development...' document close at hand)
DefaultConfigurationBuilder builder = new DefaultConfigurationBuilder();
Configuration sysConfig = builder.buildFromFile("E:/development/wiki/src/conf/avalon-wiki.xml");
Configuration roleConfig = builder.buildFromFile("E:/development/wiki/src/conf/roles.xml");
RoleManager roles = new DefaultRoleManager();
roles.configure(roleConfig);
and I get this
[javac] E:\development\wiki\src\gr\umbra\wiki\avalon\WikiBean.java:44: Method configure(org.apache.avalon.framework.configuration.Configuration) not found in interface org.apache.avalon.excalibur.component.RoleManager.
[javac] roles.configure(roleConfig);
using Excalibur-4.0b4 and Framework 4.0b3. Which is actually correct. The question is, how do I configure the RoleManager component?
Thanks.-
P.S.
If there is another list more appropriate for these questions flame me and point it out :))
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [RT] Schema & Namespace Aware Configuration
Posted by Giacomo Pati <gi...@apache.org>.
Quoting Peter Donald <do...@apache.org>:
> Hi,
>
> This sounds familiar - was it you or Fede who said we would never need
> Namespace info last time ? ;)
>
> On Fri, 21 Sep 2001 04:00, Berin Loritsch wrote:
> > The delimna is that we need to provide a solution that is:
> > * Easy to use
> > * Provides minimal impact on the current API
> > * Satisfies a need
> > * Easily extendable
>
> works for me.
>
> > The Configuration object's use can be further helped by the
> > following additional information: Namespace and Qualified name.
> > The Configuration object specifies the method getLocation().
> > It's use is not well documented, so it can be purposed to record
> > the namespace.
>
> *cough* - I use it in a lot of my proggies to specify where an error
> occured
> as do some of the exception reporting in core Avalon. It allows us to
> give
> meaningful error messages (ie "Missing attribute foo at
> myconfig.xml:20").
>
> > The name of the component would be bound to
> > the local name in the XML. The last remaining issue is the
> > prefix or qName. Because the prefix is not as important as
> > the local name or the namespace, a new accessor method can be
> > provided called "getExtendedName()". It would work like this:
>
> If we were to go down this path I would possibly prefer something like
>
> getNamespace()
> class Namespace
> {
> String prefix;
> String uri;
> }
>
> > This does not interfere with the current API, and only provides
> > one additional method. What it does allow is the ability to use
> > industry standards for configuration (WSDL, WSDD, etc.) and to
> > take advantage of dynamic validation of our configuration schemas.
> > XML parsers can read the configuration information and validate
> > the file based on the various schemas, throwing exceptions when
> > the configuration is invalid.
>
> They can still do that at the moment without any support from
> Configuration
> object. So Schema/DTD is good but doesn't madate changes in
> Configuration
> object.
>
> The argument goes that all configuration for a single object will always
> be
> in one namespace. Thus it is up to the container to do validation et al.
> The
> reason I wanted Namespace recorded in Configuration was when we had
> hierarchial Configurations. ie Component A contains B which contains C.
> If
> config for A also contains config for B (and then C) then we would
> namespace
> separation.
>
> However as it stands that was identified as a bad pattern because you
> could
> never fully validate C (or B) without initializing A. And considering
> initialization of A comes after validation of As configuration we had a
> problem.
>
> So what do you think of that ?
>
> > Each persistence mechanism must follow its own rules. However, it is
> > conceivable to convert your persisted data into XML which is then able
> > to be handled in the expected manner. This reduces the amount of
> learning
> > curve, hides the details of the persistence mechanism, and allows you
> > to focus on the task at hand.
>
> Thats what I was planning on doing (when I got around to it). ie
> DB/LDAP/XML
> to SAX, SAX to Configuration object (and vice versa).
>
> > It also allows for new tools to be developed. Tools are used to
> augment
> > the development process, the configuration process, or the deployment
> > process. Tools are not used directly in the run-time system--so they
> > should not be part of any of our existing projects.
>
> Agreed. As a sidenote has anyone looked at Merlot (opensource XML
> editor). It
> looked good last time I looked at it however it only allowed structure
> specified through a DTD (not XSchema). I was wondering if there is any
> alternatives out there?
XEmacs ;)
Giacomo
>
> --
> Cheers,
>
> Pete
>
> --------------------------------------------
> Beer is proof that God loves us and wants
> us to be happy. -- Benjamin Franklin
> --------------------------------------------
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [Bug?]: SingleThreaded vs. Poolable
Posted by Berin Loritsch <bl...@apache.org>.
Vassilis Rizopoulos wrote:
>
> *********** REPLY SEPARATOR ***********
>
> On 21.09.2001 at 09:01 Berin Loritsch wrote:
>
> >Carsten Ziegeler wrote:
> >>
> >> Hi,
> >>
> >> I just wanted to make a SingleThreaded component poolable. Is this
> >> not allowed?
> >
> >They are not allowed. Currently SingleThreaded marks interfaces that
> >cannot be reused, and must be used in one thread at a time. Therefore,
> >they are manufactured by the Factory method.
>
> I was under the impression that Poolable components are SingleThreaded implicitly - at least the concept implies that.
> So to combine the two interfaces (if it was allowed, anyway) is overkill.
> V.-
This is true.
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [Bug?]: SingleThreaded vs. Poolable
Posted by Vassilis Rizopoulos <va...@zuehlke.com>.
*********** REPLY SEPARATOR ***********
On 21.09.2001 at 09:01 Berin Loritsch wrote:
>Carsten Ziegeler wrote:
>>
>> Hi,
>>
>> I just wanted to make a SingleThreaded component poolable. Is this
>> not allowed?
>
>They are not allowed. Currently SingleThreaded marks interfaces that
>cannot be reused, and must be used in one thread at a time. Therefore,
>they are manufactured by the Factory method.
I was under the impression that Poolable components are SingleThreaded implicitly - at least the concept implies that.
So to combine the two interfaces (if it was allowed, anyway) is overkill.
V.-
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: AW: [Bug?]: SingleThreaded vs. Poolable
Posted by Berin Loritsch <bl...@apache.org>.
Carsten Ziegeler wrote:
>
> > Berin Loritsch wrote:
> >
> > Carsten Ziegeler wrote:
> > >
> > > Thanks for your explanation, Berin!
> > >
> > > I understand the difference, but - as I'm not a java expert - does
> > > not know, what makes a component SingleThreaded. Which circumstances
> > > must occur to declare a component so?
> >
> > Honestly, it is very rare that a compoent can't be used again. However,
> > Xerces happens to make one. I wish I new _why_ it was not reusable.
> > Basically, if the complexity of the component is such that it cannot
> > reset itself automatically, then you must implement it in a SingleThreaded
> > manner.
> >
> Ok, this means the component is only usable exactly one-time. This has in
> my opinion nothing to do with SingleThreaded. But ok, it's the way it is.
>
> > The rest of the time Poolable or Recyclable will work.
> >
> > > One of the components I wanted to make singlethreaded is the JaxpParser
> > > in Cocoon2 (and that's actually the reason why I ask this question).
> > > I don't see any specific code in that class.
> >
> > JaxpParser is SingleThreaded--at least the last time I committed it was.
> > It should be implementing the SingleThreaded interface.
> >
> It still is, but if I understand you right, we could make the Jaxp parser
> Poolable when it instantiates a new (Xerces) parser object each time it
> it is get from the pool. This would slightly reduce object creation (
> and new configuration of the JaxpParser).
> Am I correct here.
You are correct.
>
> Carsten
>
> >
> > The mechanics are these:
> >
> > If a component implements a lifestyle interface (SingleThreaded, Poolable,
> > or ThreadSafe) it is used. They are mutually exclusive--however there is
> > no Java mechanism to enforce this in the compiler--so it will not
> > complain.
> >
> > If a component does not declare any lifecycle interface then it is treated
> > as SingleThreaded. This is not optimal, but it is the safest
> > assumption that
> > the CM can make. Therefore implementing Poolable or ThreadSafe
> > are optimizations
> > to the run-time.
> >
> > >
> > > Carsten
> > >
> > > > Berin Loritsch wrote:
> > > >
> > > > Carsten Ziegeler wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > I just wanted to make a SingleThreaded component poolable. Is this
> > > > > not allowed?
> > > >
> > > > They are not allowed. Currently SingleThreaded marks interfaces that
> > > > cannot be reused, and must be used in one thread at a time.
> > Therefore,
> > > > they are manufactured by the Factory method.
> > > >
> > > > Poolable components (inherently only run in one thread at a time) can
> > > > be reused, therefore when one thread is done with it, it is returned
> > > > to the pool.
> > > >
> > > > Notice the distinction.
> > > >
> > > > > I get an exception from the excalibur component manager, which does
> > > > > the following test:
> > > > > >>>
> > > > > if (SingleThreaded.class.isAssignableFrom(componentClass))
> > > > > {
> > > > > numInterfaces++;
> > > > > }
> > > > >
> > > > > if (ThreadSafe.class.isAssignableFrom(componentClass))
> > > > > {
> > > > > numInterfaces++;
> > > > > }
> > > > >
> > > > > if (Poolable.class.isAssignableFrom(componentClass))
> > > > > {
> > > > > numInterfaces++;
> > > > > }
> > > > > <<<
> > > > > This means these interfaces can not combined. I agree that
> > > > > SingleThreaded and ThreadSafe are not possible and
> > > > > ThreadSafe and Poolable don't make sense, but
> > > > > Poolable and SingleThreaded seems ok to me.
> > > > > Or am I wrong?
> > > > >
> > > > > Carsten
> > > > >
> > > > >
> > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
> > > > > For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
AW: [Bug?]: SingleThreaded vs. Poolable
Posted by Carsten Ziegeler <cz...@sundn.de>.
> Berin Loritsch wrote:
>
> Carsten Ziegeler wrote:
> >
> > Thanks for your explanation, Berin!
> >
> > I understand the difference, but - as I'm not a java expert - does
> > not know, what makes a component SingleThreaded. Which circumstances
> > must occur to declare a component so?
>
> Honestly, it is very rare that a compoent can't be used again. However,
> Xerces happens to make one. I wish I new _why_ it was not reusable.
> Basically, if the complexity of the component is such that it cannot
> reset itself automatically, then you must implement it in a SingleThreaded
> manner.
>
Ok, this means the component is only usable exactly one-time. This has in
my opinion nothing to do with SingleThreaded. But ok, it's the way it is.
> The rest of the time Poolable or Recyclable will work.
>
> > One of the components I wanted to make singlethreaded is the JaxpParser
> > in Cocoon2 (and that's actually the reason why I ask this question).
> > I don't see any specific code in that class.
>
> JaxpParser is SingleThreaded--at least the last time I committed it was.
> It should be implementing the SingleThreaded interface.
>
It still is, but if I understand you right, we could make the Jaxp parser
Poolable when it instantiates a new (Xerces) parser object each time it
it is get from the pool. This would slightly reduce object creation (
and new configuration of the JaxpParser).
Am I correct here.
Carsten
>
> The mechanics are these:
>
> If a component implements a lifestyle interface (SingleThreaded, Poolable,
> or ThreadSafe) it is used. They are mutually exclusive--however there is
> no Java mechanism to enforce this in the compiler--so it will not
> complain.
>
> If a component does not declare any lifecycle interface then it is treated
> as SingleThreaded. This is not optimal, but it is the safest
> assumption that
> the CM can make. Therefore implementing Poolable or ThreadSafe
> are optimizations
> to the run-time.
>
> >
> > Carsten
> >
> > > Berin Loritsch wrote:
> > >
> > > Carsten Ziegeler wrote:
> > > >
> > > > Hi,
> > > >
> > > > I just wanted to make a SingleThreaded component poolable. Is this
> > > > not allowed?
> > >
> > > They are not allowed. Currently SingleThreaded marks interfaces that
> > > cannot be reused, and must be used in one thread at a time.
> Therefore,
> > > they are manufactured by the Factory method.
> > >
> > > Poolable components (inherently only run in one thread at a time) can
> > > be reused, therefore when one thread is done with it, it is returned
> > > to the pool.
> > >
> > > Notice the distinction.
> > >
> > > > I get an exception from the excalibur component manager, which does
> > > > the following test:
> > > > >>>
> > > > if (SingleThreaded.class.isAssignableFrom(componentClass))
> > > > {
> > > > numInterfaces++;
> > > > }
> > > >
> > > > if (ThreadSafe.class.isAssignableFrom(componentClass))
> > > > {
> > > > numInterfaces++;
> > > > }
> > > >
> > > > if (Poolable.class.isAssignableFrom(componentClass))
> > > > {
> > > > numInterfaces++;
> > > > }
> > > > <<<
> > > > This means these interfaces can not combined. I agree that
> > > > SingleThreaded and ThreadSafe are not possible and
> > > > ThreadSafe and Poolable don't make sense, but
> > > > Poolable and SingleThreaded seems ok to me.
> > > > Or am I wrong?
> > > >
> > > > Carsten
> > > >
> > > >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: AW: [Bug?]: SingleThreaded vs. Poolable
Posted by Berin Loritsch <bl...@apache.org>.
Carsten Ziegeler wrote:
>
> Thanks for your explanation, Berin!
>
> I understand the difference, but - as I'm not a java expert - does
> not know, what makes a component SingleThreaded. Which circumstances
> must occur to declare a component so?
Honestly, it is very rare that a compoent can't be used again. However,
Xerces happens to make one. I wish I new _why_ it was not reusable.
Basically, if the complexity of the component is such that it cannot
reset itself automatically, then you must implement it in a SingleThreaded
manner.
The rest of the time Poolable or Recyclable will work.
> One of the components I wanted to make singlethreaded is the JaxpParser
> in Cocoon2 (and that's actually the reason why I ask this question).
> I don't see any specific code in that class.
JaxpParser is SingleThreaded--at least the last time I committed it was.
It should be implementing the SingleThreaded interface.
The mechanics are these:
If a component implements a lifestyle interface (SingleThreaded, Poolable,
or ThreadSafe) it is used. They are mutually exclusive--however there is
no Java mechanism to enforce this in the compiler--so it will not complain.
If a component does not declare any lifecycle interface then it is treated
as SingleThreaded. This is not optimal, but it is the safest assumption that
the CM can make. Therefore implementing Poolable or ThreadSafe are optimizations
to the run-time.
>
> Carsten
>
> > Berin Loritsch wrote:
> >
> > Carsten Ziegeler wrote:
> > >
> > > Hi,
> > >
> > > I just wanted to make a SingleThreaded component poolable. Is this
> > > not allowed?
> >
> > They are not allowed. Currently SingleThreaded marks interfaces that
> > cannot be reused, and must be used in one thread at a time. Therefore,
> > they are manufactured by the Factory method.
> >
> > Poolable components (inherently only run in one thread at a time) can
> > be reused, therefore when one thread is done with it, it is returned
> > to the pool.
> >
> > Notice the distinction.
> >
> > > I get an exception from the excalibur component manager, which does
> > > the following test:
> > > >>>
> > > if (SingleThreaded.class.isAssignableFrom(componentClass))
> > > {
> > > numInterfaces++;
> > > }
> > >
> > > if (ThreadSafe.class.isAssignableFrom(componentClass))
> > > {
> > > numInterfaces++;
> > > }
> > >
> > > if (Poolable.class.isAssignableFrom(componentClass))
> > > {
> > > numInterfaces++;
> > > }
> > > <<<
> > > This means these interfaces can not combined. I agree that
> > > SingleThreaded and ThreadSafe are not possible and
> > > ThreadSafe and Poolable don't make sense, but
> > > Poolable and SingleThreaded seems ok to me.
> > > Or am I wrong?
> > >
> > > Carsten
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
AW: [Bug?]: SingleThreaded vs. Poolable
Posted by Carsten Ziegeler <cz...@sundn.de>.
Thanks for your explanation, Berin!
I understand the difference, but - as I'm not a java expert - does
not know, what makes a component SingleThreaded. Which circumstances
must occur to declare a component so?
One of the components I wanted to make singlethreaded is the JaxpParser
in Cocoon2 (and that's actually the reason why I ask this question).
I don't see any specific code in that class.
Carsten
> Berin Loritsch wrote:
>
> Carsten Ziegeler wrote:
> >
> > Hi,
> >
> > I just wanted to make a SingleThreaded component poolable. Is this
> > not allowed?
>
> They are not allowed. Currently SingleThreaded marks interfaces that
> cannot be reused, and must be used in one thread at a time. Therefore,
> they are manufactured by the Factory method.
>
> Poolable components (inherently only run in one thread at a time) can
> be reused, therefore when one thread is done with it, it is returned
> to the pool.
>
> Notice the distinction.
>
> > I get an exception from the excalibur component manager, which does
> > the following test:
> > >>>
> > if (SingleThreaded.class.isAssignableFrom(componentClass))
> > {
> > numInterfaces++;
> > }
> >
> > if (ThreadSafe.class.isAssignableFrom(componentClass))
> > {
> > numInterfaces++;
> > }
> >
> > if (Poolable.class.isAssignableFrom(componentClass))
> > {
> > numInterfaces++;
> > }
> > <<<
> > This means these interfaces can not combined. I agree that
> > SingleThreaded and ThreadSafe are not possible and
> > ThreadSafe and Poolable don't make sense, but
> > Poolable and SingleThreaded seems ok to me.
> > Or am I wrong?
> >
> > Carsten
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [Bug?]: SingleThreaded vs. Poolable
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Berin Loritsch a écrit :
>
> Torsten Curdt wrote:
> >
> > Hi, that's exactly what I was wondering, too
> >
> > > > Hi,
> > > >
> > > > I just wanted to make a SingleThreaded component poolable. Is this
> > > > not allowed?
> > >
> > > They are not allowed. Currently SingleThreaded marks interfaces that
> > > cannot be reused, and must be used in one thread at a time. Therefore,
> > > they are manufactured by the Factory method.
> >
> > But why?! I have a component that is not ThreadSafe (and therefor I would
> > like to declare it SingleThreaded. But it since it is just a helper component
> > and there is no need to create new instances all the time I'd like to
> > make it Rececylable (extends Poolable)
> >
> > What is wrong with this approach?
>
> If it can be reused, then make it Recyclable--that implcitly makes the component
> Poolable. There is not problem with that approach. However, if for reasons
> beyond _your_ control the component cannot be reused you must use the SingleThreaded
> interface.
>
> > > Poolable components (inherently only run in one thread at a time) can
> >
> > So Poolable should extend SingleThreaded ?!
>
> Theorhetically, this may be true. Poolable is a special case of a component
> that must be single threaded. However, the SingleThreaded concept is familiar
> to Servlet writers who use the variation of the Servlet that forces a new copy
> to be created for each request--or serialize all accesses to it so only one
> thread accesses it at a time. Clearly not optimal--though sometimes necessary.
>
> >
> > > be reused, therefore when one thread is done with it, it is returned
> > > to the pool.
> > --
> > Torsten
> >
I also questioned myself about the relationship between SingleThreaded
and Poolable. A poolable object is one that isn't ThreadSafe and whose
creation cost (instantiation and initialization) justify to keep created
instances in the pool for later reuse instead of throwing them to
garbage.
Forbidding SingleThreaded _and_ Poolable means you cannot have a simple
stateful component implementation marked SingleThreaded and a subclass
of it marked Poolable, while both are equally not ThreadSafe.
So, IMO, this greatly limits the usefullness of SingleThreaded : people
won't use it because it's equivalent to having no lifestyle marker, but
forbids Poolable subclasses. We should be able to use SingleThreaded to
strongly mark classes that _cannot_ be made ThreadSafe by subclassing
them, without any assumption on poolable/not poolable.
--
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [Bug?]: SingleThreaded vs. Poolable
Posted by Berin Loritsch <bl...@apache.org>.
Torsten Curdt wrote:
>
> Hi, that's exactly what I was wondering, too
>
> > > Hi,
> > >
> > > I just wanted to make a SingleThreaded component poolable. Is this
> > > not allowed?
> >
> > They are not allowed. Currently SingleThreaded marks interfaces that
> > cannot be reused, and must be used in one thread at a time. Therefore,
> > they are manufactured by the Factory method.
>
> But why?! I have a component that is not ThreadSafe (and therefor I would
> like to declare it SingleThreaded. But it since it is just a helper component
> and there is no need to create new instances all the time I'd like to
> make it Rececylable (extends Poolable)
>
> What is wrong with this approach?
If it can be reused, then make it Recyclable--that implcitly makes the component
Poolable. There is not problem with that approach. However, if for reasons
beyond _your_ control the component cannot be reused you must use the SingleThreaded
interface.
> > Poolable components (inherently only run in one thread at a time) can
>
> So Poolable should extend SingleThreaded ?!
Theorhetically, this may be true. Poolable is a special case of a component
that must be single threaded. However, the SingleThreaded concept is familiar
to Servlet writers who use the variation of the Servlet that forces a new copy
to be created for each request--or serialize all accesses to it so only one
thread accesses it at a time. Clearly not optimal--though sometimes necessary.
>
> > be reused, therefore when one thread is done with it, it is returned
> > to the pool.
> --
> Torsten
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: [Bug?]: SingleThreaded vs. Poolable
Posted by Torsten Curdt <tc...@dff.st>.
Hi, that's exactly what I was wondering, too
> > Hi,
> >
> > I just wanted to make a SingleThreaded component poolable. Is this
> > not allowed?
>
> They are not allowed. Currently SingleThreaded marks interfaces that
> cannot be reused, and must be used in one thread at a time. Therefore,
> they are manufactured by the Factory method.
But why?! I have a component that is not ThreadSafe (and therefor I would
like to declare it SingleThreaded. But it since it is just a helper component
and there is no need to create new instances all the time I'd like to
make it Rececylable (extends Poolable)
What is wrong with this approach?
> Poolable components (inherently only run in one thread at a time) can
So Poolable should extend SingleThreaded ?!
> be reused, therefore when one thread is done with it, it is returned
> to the pool.
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [Bug?]: SingleThreaded vs. Poolable
Posted by Berin Loritsch <bl...@apache.org>.
Carsten Ziegeler wrote:
>
> Hi,
>
> I just wanted to make a SingleThreaded component poolable. Is this
> not allowed?
They are not allowed. Currently SingleThreaded marks interfaces that
cannot be reused, and must be used in one thread at a time. Therefore,
they are manufactured by the Factory method.
Poolable components (inherently only run in one thread at a time) can
be reused, therefore when one thread is done with it, it is returned
to the pool.
Notice the distinction.
> I get an exception from the excalibur component manager, which does
> the following test:
> >>>
> if (SingleThreaded.class.isAssignableFrom(componentClass))
> {
> numInterfaces++;
> }
>
> if (ThreadSafe.class.isAssignableFrom(componentClass))
> {
> numInterfaces++;
> }
>
> if (Poolable.class.isAssignableFrom(componentClass))
> {
> numInterfaces++;
> }
> <<<
> This means these interfaces can not combined. I agree that
> SingleThreaded and ThreadSafe are not possible and
> ThreadSafe and Poolable don't make sense, but
> Poolable and SingleThreaded seems ok to me.
> Or am I wrong?
>
> Carsten
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
[Bug?]: SingleThreaded vs. Poolable
Posted by Carsten Ziegeler <cz...@sundn.de>.
Hi,
I just wanted to make a SingleThreaded component poolable. Is this
not allowed?
I get an exception from the excalibur component manager, which does
the following test:
>>>
if (SingleThreaded.class.isAssignableFrom(componentClass))
{
numInterfaces++;
}
if (ThreadSafe.class.isAssignableFrom(componentClass))
{
numInterfaces++;
}
if (Poolable.class.isAssignableFrom(componentClass))
{
numInterfaces++;
}
<<<
This means these interfaces can not combined. I agree that
SingleThreaded and ThreadSafe are not possible and
ThreadSafe and Poolable don't make sense, but
Poolable and SingleThreaded seems ok to me.
Or am I wrong?
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [RT] Schema & Namespace Aware Configuration
Posted by Peter Donald <do...@apache.org>.
Hi,
This sounds familiar - was it you or Fede who said we would never need
Namespace info last time ? ;)
On Fri, 21 Sep 2001 04:00, Berin Loritsch wrote:
> The delimna is that we need to provide a solution that is:
> * Easy to use
> * Provides minimal impact on the current API
> * Satisfies a need
> * Easily extendable
works for me.
> The Configuration object's use can be further helped by the
> following additional information: Namespace and Qualified name.
> The Configuration object specifies the method getLocation().
> It's use is not well documented, so it can be purposed to record
> the namespace.
*cough* - I use it in a lot of my proggies to specify where an error occured
as do some of the exception reporting in core Avalon. It allows us to give
meaningful error messages (ie "Missing attribute foo at myconfig.xml:20").
> The name of the component would be bound to
> the local name in the XML. The last remaining issue is the
> prefix or qName. Because the prefix is not as important as
> the local name or the namespace, a new accessor method can be
> provided called "getExtendedName()". It would work like this:
If we were to go down this path I would possibly prefer something like
getNamespace()
class Namespace
{
String prefix;
String uri;
}
> This does not interfere with the current API, and only provides
> one additional method. What it does allow is the ability to use
> industry standards for configuration (WSDL, WSDD, etc.) and to
> take advantage of dynamic validation of our configuration schemas.
> XML parsers can read the configuration information and validate
> the file based on the various schemas, throwing exceptions when
> the configuration is invalid.
They can still do that at the moment without any support from Configuration
object. So Schema/DTD is good but doesn't madate changes in Configuration
object.
The argument goes that all configuration for a single object will always be
in one namespace. Thus it is up to the container to do validation et al. The
reason I wanted Namespace recorded in Configuration was when we had
hierarchial Configurations. ie Component A contains B which contains C. If
config for A also contains config for B (and then C) then we would namespace
separation.
However as it stands that was identified as a bad pattern because you could
never fully validate C (or B) without initializing A. And considering
initialization of A comes after validation of As configuration we had a
problem.
So what do you think of that ?
> Each persistence mechanism must follow its own rules. However, it is
> conceivable to convert your persisted data into XML which is then able
> to be handled in the expected manner. This reduces the amount of learning
> curve, hides the details of the persistence mechanism, and allows you
> to focus on the task at hand.
Thats what I was planning on doing (when I got around to it). ie DB/LDAP/XML
to SAX, SAX to Configuration object (and vice versa).
> It also allows for new tools to be developed. Tools are used to augment
> the development process, the configuration process, or the deployment
> process. Tools are not used directly in the run-time system--so they
> should not be part of any of our existing projects.
Agreed. As a sidenote has anyone looked at Merlot (opensource XML editor). It
looked good last time I looked at it however it only allowed structure
specified through a DTD (not XSchema). I was wondering if there is any
alternatives out there?
--
Cheers,
Pete
--------------------------------------------
Beer is proof that God loves us and wants
us to be happy. -- Benjamin Franklin
--------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org