avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: Is everyone happy with Namespace?
Date Fri, 09 Nov 2001 22:48:55 GMT
Peter Donald wrote:
> 
> On Sat, 10 Nov 2001 09:23, Berin Loritsch wrote:
> > Peter Donald wrote:
> > > On Sat, 10 Nov 2001 01:23, Sylvain Wallez wrote:
> > > > Berin Loritsch a �rit :
> > > > > I want to clarify if everyone is happy with the Namespace
> > > > > class.  We need to take care of it NOW before it is too
> > > > > late!
> > > >
> > > > Namespace info and Configuration names are OK for me, but a few
> > > > questions about the prefix validation in Namespace.equals() :
> > >
> > > what is validation meant to do ? Neither the policy or m_validate_prefix
> > > seem to be used.
> >
> > Hmm.
> >
> > Ok the policy is supposed to be a flag to use the prefix during
> > comparisons of Namespace objects or not.
> >
> > I.e.
> >
> > pre1:element
> > pre2:element
> >
> > Where pre1 and pre2 are set to "test-uri/namespace"
> >
> > With m_validate_prefix set to true, the two namespaces would be
> > considered different.  So .equals() would return false.
> >
> > With m_validate_prefix set to false, the two namespaces are
> > considered the same (the all important URI is the same).  So
> > .equals() would return true.
> 
> when would you want validate_prefix to be set to true? Doesn't that violate
> basic principles of XML ? So I can think of a place I would like to use it
> but then again that case is an ugly hack. Is there any legitimate uses for
> this? ;)

According to the XML Namespace spec, officially the namespace is different
if the prefix is different.  Of course, I may be applying something only
meant for attributes to elements.

In the end, I would like them to be treated the same even if the prefix
is different--but that could have been accomplished by removing the
Namespace object and ONLY keeping the URI in the configuration.

> > > > - is this good to have a static setting for this policy in a
> > > > multi-thread/multi-app environment ?
> > >
> > > probably not.
> >
> > How often do you create new Namespace objects?
> Every time you create a Config tree ;)

Usually done in one thread at init time.

> > Also, wouldn't you
> > want the same policy accross the board?
> 
> no.
> 
> Example: when ant2 goes live and I finally commit my jobserver,
> ant2/jobserver will possibly be using a different policy than main
> phoenix.

I see.

> > The Factory methods (.getNamespace(String)) can be extended to
> > simply have a boolean to set the policy for the object.
> >
> > However you must keep in mind that multiple policies for comparing
> > Namespace objects has unpredictable results.  (actually it will
> > use the policy of the Namespace object on the left side of the
> > argument).
> 
> you probably shouldn't be comparing namespace objects across domains anyway -
> I would consider that an error in the code.

So does the change to the factory method sound like the way to go?



-- 

"Those who would trade liberty for
 temporary security deserve neither"
                - Benjamin Franklin

--
To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Mime
View raw message