problem with Crimson parser

[gk]

".....Crimson parser is bundled by default with JDK 1.4.To override
this parser we need to run our example with -Djava.endorsed.dirs
option....."


(1) why people dont want to use Crimson parser ?

(2) according to above comment , so we can run like this..
java -classpath .; -Djava.endorsed.dirs=c:\xerces\lib SAXParserExample

what does "-Djava.endorsed.dirs" do ? it says "override" ....how
does JVM identifies it ? does it searches the "c:\xerces\lib"
directory and try to match whether there is a similar kind of API
already exists in JDK or not ? if it finds , then it overrides with
the new one ......does it work this way ?

(3) ok, we can override the XML parser for JVM as above....but how do
we do it , when its an web application.

For example, i have a server which has a XML parser shipped with it
......but i am using "xerces" ..... in this case , how do i override it
and where to override it ? how can i reject the parser shipped with the
server and adopt the new one which i am using ?

what is the command for that ?


I am not specifying the server name . because , if i say Tomcat ...then
you might say, delete the JAR files from servers lib directory (really,
is it a solution ?) and it will automatically picks up your new JAR
file "xerces"....but there must be some other way out without deleting
the JAR files shipped with the server.....is not it ?

how do i override then in a web/app container ?

my preffered servers are jboss,weblogic,websphere,sun,and tomcat

 

[=?gb2312?B?yMrV387etdA=?=]

(1) because apache xerces is better,and sun did not realize it until
1.5.
(2)It is a way for you to override the classes of the jre classes.You
can even override java.lang.String by this way.JRE will prefer the
classes here than regular place. This way is provided for the some api
that changes more frequently than JCP,for example,the DOM standard,
CORBA standard are supposed to use this way to override the deprecated
api by this way if they are newer.
see ref:
http://java.sun.com/j2se/1.5.0/docs/guide/standards/index.html
it says other packages may not be overriden,but it can be......

(3)I think you should survey the doc,and find the launcher option of
the server,may be an evironment variable in a shell or in some
textfield of some manager gui,you can still use this method to override
the standard api.



"gk дµÀ£º
"

 

[Simon Brooke]

".....Crimson parser is bundled by default with JDK 1.4.To override
this parser we need to run our example with -Djava.endorsed.dirs
option....."

(1) why people dont want to use Crimson parser ?

I do use it, but it's old and no longer really supported so I ought to sort
out the problems I'm having with Xerces.

(2) according to above comment , so we can run like this..
java -classpath .; -Djava.endorsed.dirs=c:\xerces\lib SAXParserExample

what does "-Djava.endorsed.dirs" do ? it says "override" ....how
does JVM identifies it ? does it searches the "c:\xerces\lib"
directory and try to match whether there is a similar kind of API
already exists in JDK or not ? if it finds , then it overrides with
the new one ......does it work this way ?
Pass.

(3) ok, we can override the XML parser for JVM as above....but how do
we do it , when its an web application.

Drop you preferred parser's JAR file into WEB-INF/lib, set up a
context-param to say which parser you want to use:

<context-param>
<param-name>dom_implementation_class</param-name>
<param-value>
org.apache.crimson.tree.DOMImplementationImpl </param-value>
<description>The DOM implementation to use. I'm currently supplying
Crimson with PRES rather than Xerces, because it
works better. </description>
</context-param>

Read that parameter and instantiate the parser you want:

String s = config.getValueAsString( "dom_implementation_class" );

if ( domImp == null )
{
try
{
if ( s != null )
{
domImpName = s;
}

domImp =
(DOMImplementation) Class.forName( domImpName )
.newInstance( );
}
catch ( Exception any )
{
throw new InitialisationException( "Could not find DOM " +
"implementation " + domImpName );
}
}

For example, i have a server which has a XML parser shipped with it
.....but i am using "xerces" ..... in this case , how do i override it
and where to override it ? how can i reject the parser shipped with the
server and adopt the new one which i am using ?

what is the command for that ?


I am not specifying the server name . because , if i say Tomcat ...then
you might say, delete the JAR files from servers lib directory (really,
is it a solution ?) and it will automatically picks up your new JAR
file "xerces"....but there must be some other way out without deleting
the JAR files shipped with the server.....is not it ?

It would be a solution to replace the jar file in the server lib directory,
but I wouldn't do that, because other webapps on the same server may
prefer the default setup. Instead, put the jar file you want in your own
webapp's lib directory, as I've suggested above.

 

[gk]

I do use it, but it's old and no longer really supported so I ought to sort
out the problems I'm having with Xerces.


Drop you preferred parser's JAR file into WEB-INF/lib, set up a
context-param to say which parser you want to use:

<context-param>
<param-name>dom_implementation_class</param-name>
<param-value>
org.apache.crimson.tree.DOMImplementationImpl </param-value>
<description>The DOM implementation to use. I'm currently supplying
Crimson with PRES rather than Xerces, because it
works better. </description>
</context-param>

ok. fine.....but you are using one particular class here this
way.....the JAR file might have many *dependent* class files .....those
also needs to be added ...is not it ? otherwise ,you will get
classnotfoundexception very soon ...and if i try to find which are the
classes which are associated with the desired one ...then i have to
dig up really which is messy and pathetic.

Read that parameter and instantiate the parser you want:

String s = config.getValueAsString( "dom_implementation_class" );

if ( domImp == null )
{
try
{
if ( s != null )
{
domImpName = s;
}

domImp =
(DOMImplementation) Class.forName( domImpName )
.newInstance( );
}
catch ( Exception any )
{
throw new InitialisationException( "Could not find DOM " +
"implementation " + domImpName );
}
}


It would be a solution to replace the jar file in the server lib directory,
but I wouldn't do that, because other webapps on the same server may
prefer the default setup. Instead, put the jar file you want in your own
webapp's lib directory, as I've suggested above.

ah ,i see . so you want to say there wont be any conflict if i put my
parser JAR file in my web-app directory.


or in other words , if i put the JAR file in my web-app's WEB-INF/lib
directory then default set-up would be deactivated and the new one
would be picked up . i dont think in this case ,i need extract the
class value and instantiate as you shown above ..right ? because
classes will be automatically loaded by the server's classloader as
these are in the classpath.

 

[Simon Brooke]

ok. fine.....but you are using one particular class here this
way.....the JAR file might have many *dependent* class files .....those
also needs to be added ...is not it ? otherwise ,you will get
classnotfoundexception very soon ...and if i try to find which are the
classes which are associated with the desired one ...then i have to
dig up really which is messy and pathetic.

No, the org.w3c.dom.DOMImplementation interface provides a handle through
which you can access all the features of a DOM parser. You can even have
two different DOM parsers loaded in the same Java VM, and use them to do
different things (although I can't see any particular advantage of this).

If you want to use a specific DOM implementation, though, in an environment
in which others may be present, this is the way to do it.

or in other words , if i put the JAR file in my web-app's WEB-INF/lib
directory then default set-up would be deactivated and the new one
would be picked up . i dont think in this case ,i need extract the
class value and instantiate as you shown above ..right ? because
classes will be automatically loaded by the server's classloader as
these are in the classpath.

Don't know. The way I've described works, and I use it - but I've been
using since before XML parsers became standard parts of a Java
environment.