> BTW, which parser is being used isn't always clear. JDK 1.4 ships with > Crimson, so it will always be in the classpath.
This is exactly what i pointed out in the last email... e.g NamedNodeMap nnm = n.getAttributes(); System.out.println(nnm); works and you can see the node as like a collection object... Now change the CLASSPATH to include 2 Xerces *.jar files.. The behaviour changes and u get some like $$Attribute printed out. what happens when the expected parser is not there with > code that isn't written to the JAXP API? It doesn't work obviously. There are only 6 Classes in JAXP...(4 Concrete, 1 Exception and 1 Error) Classes(DocumentBuilder,DocumentBuilderFactory,SAXParser,SAXParserFactory) Exceptions(ParserConfigurationException) Errors(FactoryConfigurationError) The correct implementation of JAXP will give a handle to the Parser Implementation.. So, if NO Parser API's are used, Crimson is default. I wonder what will happen if you add "xerces2 J" to CFMX 6.1 ClassPath? Joe Eugene ----- Original Message ----- From: "Matt Liotta" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, September 10, 2003 4:14 PM Subject: Re: [CFCDev] Java DOM API's(Crimson/Xerces) in CFMX 6.1 Or RedSky > > Thanks for the additional information and clarification. Is this just > > J2EE > > Phase 2? Does the dependency still exist for CFMX 6.1? I run CFMX > > 6.1 J2EE > > on WebLogic 7 and I know from past experience that it uses Xerces and > > has > > Xerces in it's classpath. > > > I haven't looked since then, so I don't know. However, the indication I > got from Macromedia was that they weren't planning on changing the > dependency on Crimson. > > BTW, which parser is being used isn't always clear. JDK 1.4 ships with > Crimson, so it will always be in the classpath. System properties, > which determine which parser to use can be set on a per container > basis, so it is possible to have one web application using one parser, > while another web application uses a different one all on the same > server. Further, assuming the parser's APIs are used directly it is > possible to have some code work with one parser, while another set of > code works with a different parser all in the same container. The > question is, what happens when the expected parser is not there with > code that isn't written to the JAXP API? It doesn't work obviously. > > Try deploying CFMX without Crimson, but with some other JAXP compliant > parser and see how it goes. Although, this whole thread is probably > useless for those making use of JDK 1.4 since there would never be a > reason to not have Crimson. > > Matt Liotta > President & CEO > Montara Software, Inc. > http://www.MontaraSoftware.com > (888) 408-0900 x901 > > > ---------------------------------------------------------- > You are subscribed to cfcdev. To unsubscribe, send an email > to [EMAIL PROTECTED] with the word 'unsubscribe cfcdev' > in the message of the email. > > CFCDev is run by CFCZone (www.cfczone.org) and supported > by Mindtool, Corporation (www.mindtool.com). > > An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED] ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the word 'unsubscribe cfcdev' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com). An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED]
