-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Max Kellermann <[EMAIL PROTECTED]> writes:
<snip>
> > I have a question to you all. Should we allow the same interface in
> > different
> > packages? It seems to create strange conflicts but sometime it is necessary,
> > or? What do you all think?
>
> That's also one thing I was thinking about. If we say we don't include DOM and
> SAX in Xerces, it's more clean IMHO, but much more work when packaging. We
> can't just call 'ant jar' to create the .JAR files, we have to create them
> ourselves. I think it's ok to have Xerces include DOM, although it's not the
> Best(tm) way.
I don't think it is just more clean... I think it is a requirement.
Specifically because I have seen this become a problem in the wild :)
A good example would be a few months back I wanted to run the latest version of
Xerces with Tomcat.
Tomcat used projectx.jar (which included an older version of DOM) and was loaded
first. When I tried to load Xerces it wasn't loading its own internal version
of DOM since the verion with projectx.jar was already loaded.
Thus I was getting an Error stating that a new method couldn't be found.
I think that Java is starting to suffer from the quote (from Knuth???)
"Those who do not learn from UNIX are destined to repeat its mistakes"
> > Do you think the above description is covered in the proposed policy. It
> > should be but I'm not sure if it is clear enough.
>
> Well, I think it's not fully covered, but it's possible with your proposed
> policy. It's not about replacing the policy, the policy is good, it's about
> adding to the policy.
>
> > > - library F and library G may both provide the sub-library H, of the same
> > > version - they may both be installed, but not in the same classpath at the
> > > same time. > > If they completely provide H, why can't they be in the
> > > same
> > > classpath? One > of them will override the other. Or am I wrong here?
>
> Yes and no.
>
> I most cases, e.g. the DOM interface classes, that's ok. They won't conflict
> because they're identical.
Not always... as above. The point is that we could do it better. :)
> But look at the TRAX API, the TRAX classes included in Xalan call concrete
> Xalan classes in the TRAX factory classes (it has to, somehow). Another XSLT
> processor will call their own concrete classes in the TRAX. So TRAX of Xalan
> conflicts with TRAX of [fill in any other TRAX-implementing XSLT processor
> here]. The same with javax.xml in XML parsers. That's what I meant here.
OK. Trax.... this is another one.
<snip>
- --
Kevin A. Burton ( [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] )
Location - San Francisco, CA, Cell - 415.595.9965
Jabber - [EMAIL PROTECTED], Web - http://relativity.yi.org/
How are you gentleman?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Get my public key at: http://relativity.yi.org/pgpkey.txt
iD8DBQE77ZG3AwM6xb2dfE0RArv/AKCTNklNF0wHInypCmO8mrfQWsVkRgCglBeO
PIG/UY5CQHS1Jh0SpjFdsPg=
=eNR4
-----END PGP SIGNATURE-----
