Duncan Higgins wrote:
Does anyone know of a good open source / open api xml diff tool ? I
would like to use something to integrate with jUnit to show diffs
between the 'expected' xml and 'result' xml generated during unit
testing. I've had a quick look at the alphaWorks xml diff tool, but I
GOMEZ Henri wrote:
More on the crimson build :
You could find attached a diff (jax.par in crimson dir and
java doc regenerated).
The problem I've got is more conceptual than technical.
When you package a RPM (maybe DEBIAN), you should allways
your build from SOURCES.
When you
Mathew, Mathew wrote:
Following exceptions get thrown when I do xml processing in a
applet(IE-Microsoft VM). I use the java xml api and use the crimson parser.
Anybody any input on how to get rid of this. From the stack trace it looks
as if the cause is the missing jaxp properties file. But
Mathew, Mathew wrote:
I am using crimson 1.1.1. The program works, it just also does the ugly
dump,
I believe that is a security feature of IE and NS does the same thing.
The Java code catches the security exceptions, but the native JVMs print
the exceptions as a security feature. So this
at
http://www.w3.org/TR/DOM-Level-2-Core/core.html#Core-Document-importNode,
it says that default attributes are _not_ copied. So I'm not yet
convinced this is a bug.
-Edwin
Regards,
Donatas
- Original Message -
From: Edwin Goei [EMAIL PROTECTED]
To: [EMAIL PROTECTED]; Donatas
[EMAIL PROTECTED] wrote:
Hi,
I'm curious about the behaviour of Crimson 1.1.1 when used as a SAX2
XMLReader. For some reason, for XML elements with no namespace, the name
is returned as the qName parameter to startElement(), rather than localName
as expected; localName is empty. We're
Shalini Gusain wrote:
Hi,
Actaully we r searching for org.apache.crimson.tree.XmlDocument api ,
but could'nt find the same
Could anybody help us in this regard
we had tried to download crimson.jar but it was not having any
XmlDocument details...
ur cooperation will be
Robert Koberg wrote:
I must be missing something very basic about DOM parsing.
Here is an excerpt of the java code:
DocumentBuilderFactory dfactory = DocumentBuilderFactory.newInstance();
DocumentBuilder docbuilder = dfactory.newDocumentBuilder();
Document doc =
Robert Koberg wrote:
The problem I am experiencing could be my misunderstanding of the DOM,
objects and servlets - so I was/am looking for guidance on how to narrow the
problem down, because as you can tell I am pretty clueless.
- When I parse a DOM Document I put it into a variable.
-
Shane Curcuru wrote:
Brief rules:
-- the file: scheme, when referring to a file on the local machine
(i.e. you don't really care about the host) will always start with
file:///, and then with an absolute path as defined by the local
environment. I'm trying to figure out what this means
[EMAIL PROTECTED] wrote:
But when I use JAXP like this :
SAXParserFactory factory = SAXParserFactory.newInstance();
SAXParser saxParser = factory.newSAXParser();
XMLReader myReader = saxParser.getXMLReader();
I can check that saxParser.isNamespaceAware() or
[EMAIL PROTECTED] wrote:
My first thought: have each project import only the specific *sources* they
need, and compile them into the .jar. This way we only have one copy of
the sources, but no need for an extra xml-apis.jar; each project will
include the minimum compiled .classes that they
Joseph Kesselman wrote:
Of these, I think I like the separate JARfile solutions better than the
experimental package approach, with the default being the most recent
recommendation (DOM2) if one absolutely must be built into the tool JARs
for convenience.
So are you saying you prefer the
Joseph Kesselman wrote:
Suppose a version of Xalan
supported DOM L2 and a newer version of Xerces came out that supported
DOM L3 then there would need to be two versions of xml-apis.jar
Or, as you noted, copying the source code in at build time... but that
raises other issues; it means
Ben Peter wrote:
Hi all,
I am working with crimson as packaged with the JAXP-1.1 distribution.
Even though I set it to non-validating and set it to not resolve external
references, crimson will try to access a DTD that is referenced in an XML
file and throw an exception if it cannot.
Andy Clark wrote:
Shane Curcuru wrote:
Note we still need to get xerces and other projects on board using the
commons copies. This might be a good excuse to get a Xerces 1.4.4
build along with any other critical bugs they might have open.
I will say again that I don't think
[EMAIL PROTECTED] wrote:
We've got a little problem in org.apache.xalan.xslt.FactoryFinder.
As currently checked in, the code won't compile under JDK 1.1.8; there's a
hard dependency on the getContextClassLoader() method, which isn't present
before JDK 1.2. We've seen that problem before,
Ted Leung wrote:
The following projects have references to the old site - at least according
to a quick
grep of the source dir in xml-site:
crimson
I'm happy to fix these in xml-site if people from these projects tell me it
is okay to do so.
Sure, it's OK with me.
-Edwin
Theodore W. Leung wrote:
I've done some minimal playing around with the top level website in
xml-site, and have modified the styles to get rid of all the images. A
version of the top level site using this style is viewable at
http://www.apache.org/~twl/new-site/index.html
Looks good. So
Tom M. Yeh wrote:
At line 433 in org.apache.crimson.tree.ElementNode2.getAttributeNodeNS
(attr.getNamespaceURI() == namespaceURI...
shall add a test of whether attr.getNamespaceURI is null. Otherwise, the following
statement will cause a NullPointerException -- while it shall
[EMAIL PROTECTED] wrote:
I believe I have run into a bug in Crimson. I get an exception when I try to import
a DocumentFragment node when it contains a child element which has attributes.
I've seen your report three times now, but unfortunately I don't have
time to look at it. Do you have a
Shane Curcuru wrote:
See this doc for the last (as I know) copy of build.xml attached that
is the basis for the 'jakarta default' build.xml file:
http://marc.theaimsgroup.com/?l=alexandria-devm=100340866808043w=2
OK, thanks for the pointer. It sounds like it hasn't stabilized yet.
-Edwin
Andy Carlson wrote:
Shane,
Thanks for your reply. Looks like there may be hope on the horizon!
BTW, not everyone agrees that having a separate xml-apis.jar file is the
best way to go. I initially thought it was a good idea, but have since
changed my mind. You can read some postings on
robert burrell donkin wrote:
this is quite a well known problem. it boils down to classloaders.
standalone tomcat 4.0 works because it has classloaders specially
rewritten to work with JAXP.
jboss uses a different system of classloaders and requires special
configuration to make JAXP
Jeff Turner wrote:
One remaining question: will it be possible for an application to
override the default parser (crimson I think), or when 1.4 is released,
are we stuck with that parser and it's bugs?
JDK 1.4 contains the JAXP 1.1 API along with the JAXP reference
implementation (RI) which
[EMAIL PROTECTED] wrote:
[snip]
I.e. to me the point is that we're agreeing to ship *stable*
externally-defined standards-based files in a jar named xml-apis.jar. Any
other files a project wants to use should go in their implementation jar,
or somewhere else; and the xml-apis.jar should
Davanum Srinivas wrote:
So, there are a few votes:
a) would you like to accept this code donation?
+1. Yes.
b) if so, where do you think it should be located?
I really like the idea of using xml-commons just like jakarta-commons (Suggestion #3
- following
the same charter and
Elliotte Rusty Harold wrote:
At 7:36 AM -0700 10/3/01, Edwin Goei wrote:
See the section on Roadmap at:
http://xml.apache.org/crimson/index.html
Basically, the plan is to move to Xerces2.
Is this just the plan for the XML Apache project, or is this also the plan for Sun's
JDKs
Shane Curcuru wrote:
like this. Sun then happend to choose to re-ship their own versions of
Crimson and Xalan as the 'reference implementations' of the actual JAXP
1.1 release - which is actually pretty cool that they chose our
implementations over other ones.
One orthogonal comment
Isaac Shabtay wrote:
Hi,
javax.xml.parsers.DocumentBuilderFactory is supposed to search for the
factory implementation in some places.
The last place to look for is:
= START QUOTE ==
• Platform default DocumentBuilderFactory instance.
= END QUOTE ==
Isaac Shabtay wrote:
Huh? I'm not sure what you mean. The JAXP specification is effectively
a bunch of interfaces that anyone can implement (along with the rest of
the docs, etc.). Apache happens to have several implementations of
Well, this I already know.
Yet,
Bentley Drake wrote:
Hello,
I'm noticing that the Crimson library seems to insert an awful lot of
whitespace into XML text streams that it generates from DOM. This
whitespace doesn't appear if a DOCTYPE reference is present, since the code
can use a validating parser and can therefore
Isaac Shabtay wrote:
Hey again.
JAXP has javax.xml.parsers.DocumentBuilderFactory and
javax.xml.transform.TransformerFactory, which are used to create a factory
implementation.
Both have some sequence of searching to the factory implementation name. One
of the steps is quoted below
Hi all,
There is a new SAX2 release out. Checking this into xml-commons and
other projects that use SAX could fix reported bugs. I'd like to
propose that this gets integrated into xml-commons and other projects
such as xerces 1, xerces 2, and xalan 2. Comments?
-Edwin
---BeginMessage---
Jay Walters wrote:
Iam finding that Crimson is very slow at performing validating parsing
of a specific XML input DTD that I am using, where very slow is
something like 1000X slower when validating. Oddly enough I'm also
seeing the same problems with Xerces 1.4 and 2.0 only if I use the
Robert Koberg wrote:
say you don't see well... try to resize your text
The issue you are pointing out has to do with accessibility. Even if
text was resizeable, such a user may not be able to see images. A
browser that seems to fix both problems is Opera with its zoom feature.
Based on his
Stefano Mazzocchi wrote:
Sam Ruby wrote:
It seems odd for a subcategory of xml.apache.org to be xml.
Yeah, I know, but couldn't find a better term.
I'd suggest parallel forms of verbs:
parse
if we do this, this category will remain locked to Xerces/Crimson
(hopefully
Stefano Mazzocchi wrote:
I received comments from people that wanted a list of sofware in
alphabetical order. Sam wants functionality grouping. You want community
grouping. Others might want importance grouping and somebody else
userbase size grouping.
One size can't fit all, expecially
Guillaume Rousse wrote:
Hello.
I'm trying to resolve problem concerning use of crimson with argouml. Latest
CVS version loads document fine using xerces-j 1.4.4, but fails using crimson
1.1.3, with following message: unable to resolve relative URI with no base
URI
Here is code snipplet:
Payal Dutt wrote:
Exception in thread main
java.lang.NullPointerException
at
org.apache.crimson.parser.Parser2.parseInternal(Parser2.java:523)
at
org.apache.crimson.parser.Parser2.parse(Parser2.java:304)
at
Payal Dutt wrote:
Hi,
Thanks for responding and suggesting.Unfortunately
it didn't work with crimson-1.1.3 either.Can you
please suggest me how to report this bug problem to
crimson.Your help is deeply appreciated.
Goto http://xml.apache.org and look for bug database on the left.
Dirk-Willem van Gulik wrote:
jaxp.
xml-batik
If this jaxp.jar came from some old distribution of the JAXP RI from
Sun, this is easy to fix. Newer versions of this code is available in
the Apache xml-commons repository. Someone from Batik can contact me if
they want help with
Theodore W. Leung wrote:
These two jars only appear in xml-contrib/spinnaker/lib. Since
spinnaker was the old name for crimson, and the CVS for it is empty, I
think that we should delete these two jars.
I think spinnaker is obsolete so deleting those jars is fine. BTW, I
don't think
Vincent Hardy wrote:
Hello,
Following Dirk's email on third-party jars we have addressed the license
issues in Batik on third-party jars (which was the point of the email),
not on jars coming from Apache code. Note that this only required moving
and renaming the license that we already
Stefan Bodewig wrote:
On 05 Feb 2002, Theodore W. Leung [EMAIL PROTECTED] wrote:
On Mon, 2002-02-04 at 22:24, Stefan Bodewig wrote:
Do we need to include an extra LICENSE.crimson
I think so.
OK, it has been a bit more difficult than I thought as Crimson doesn't
have a LICENSE in
Dirk-Willem van Gulik wrote:
On Tue, 5 Feb 2002, Edwin Goei wrote:
..
There are different versions of Crimson. Old versions used a jaxp.jar
binary from Sun that shipped w/ the Sun Binary Code License. Newer
versions of Crimson use code from xml-commons that are under the ASF
Simon McClenahan wrote:
I want to bundle a JAXP compliant XML parser with my application, with
the requirement that the jar file is as small as possible. From what I
can tell, between Crimson, Xerces1 and Xerces2, I am using Crimson
because of its smaller jar size. However, if there is a
Simon McClenahan wrote:
The Crimson jar has
META-INF/services/javax.xml.parsers.DocumentBuilderFactory file, as
specified in the javax.xml.parsers.DocumentBuilderFactory#newInstance()
JavaDoc. Is this different than the Jar Service Provider example given
above in the JAXP FAQ?
The
Christophe Jolif wrote:
Hi,
The following small test case crashes with crimson (cvs snapshot):
import org.w3c.dom.*;
import org.apache.crimson.tree.*;
public class BugB
{
// CJO 02/2002
public static void main(String[] arg) {
// directly create XmlDocument
Shane Curcuru wrote:
However, if you look at the CVS tags, you can kind of see which
versions of the files were used as the base of Sun's official JAXP
releases. Of course Apacheites can't promise that our versions will
be/are the actual versions that Sun will ship with a particular
Hi all,
I've updated the JAXP API classes under the javax.xml.{parsers,
transform} packages to implement the following:
1) Added doPrivilege blocks so the code can be used in environments such
as servlet and EJB containers which have SecurityManagers installed. (I
believe this is required
Edwin Goei wrote:
James Strachan wrote:
Yes - I'll try sort this out. I'll ensure that all the xml-apis.jar
versions
are actually full copies of JAXP. (Probably by just replacing any dodgy
copies with the latest that ships with Xalan)
BTW, Sun does not ship a single xml-apis.jar
52 matches
Mail list logo
