Hello, all.
Reviving an old thead, here.
I stated in this
thread that we don't want any compile dependencies on any particular
parser.
Well, that is
really more restrictive than our real requirement -- which I kind of forgot
about.
Our main issue is
that we must be able to select a parser even if we don't
have control of
the order of jars in the classpath (like with many ejb/servlet
containers).
Here is one way
to select your parser without regard to the order of jars in the
cp.
For instance, say
we want to use the oracle parser instead of xerces.
1) Configure
Castor to use JAXP's "select a parser" feature. One way to do this is to
comment out the
setting org.exolab.castor.parser in the castor.properties
file.
2) Make a copy of
xerces.jar and delete these two files
/META-INF/services/javax.xml.parsers.DocumentBuilderFactory
/META-INF/services/javax.xml.parsers.SAXParserFactory
This insures that JAXP won't
use xerces as the parser.
3) put this 'modified'
xerces.jar into the classpath -- castor
needs it for its
org.apache.xml.serialize.XMLSerializer.
4) Place the your JAXP
compliant parser's jar (xmlparserv2.jar, for instance) into the
CP.
If you're curious
about this META-INF/services stuff, here's some more detail:
--Erik
-----Original Message-----One last thing. the person implementing ParserGenerator could use reflection to load his parser. Then there is a runtime dependency and no compile time dependency. It is the ParserGenerator's implementor that has the choice.
From: Dean Hiller [mailto:[EMAIL PROTECTED]
Sent: Saturday, April 19, 2003 7:00 AM
To: [EMAIL PROTECTED]
Subject: Re: [castor-dev] jaxp / parser configuration
dean
Keith Visco wrote:
I agree with Erik on this one, that's why we need to come up with a way to abstract the Serializer as well. Thanks, --Keith "Ostermueller, Erik" wrote:One further requirement, Dean. We don't want to have any compile dependencies on any particular parser. We want to be able to plug in an implementation jar, quickly modify a configuration file and go with it. --eto > -----Original Message----- > From: Dean Hiller [mailto:[EMAIL PROTECTED]] > Sent: Friday, April 18, 2003 4:35 PM > To: [EMAIL PROTECTED] > Subject: Re: [castor-dev] jaxp / parser configuration > > > yes, I was not very clear on that. The parser is used > two times as far > as I can tell. It is used when using castor to > generate code from an > xsd(this is what I meant by build time). It is also used when > marshalling/unmarshalling objects(this is what I meant > by runtime). > Again I was very unclear about it. I hope this clears > it up. I only > need to change the parser when > marshalling/unmarshalling, and it sounds > like that is the same with your stuff and it might be > the same for > everyone else too. Anybody else need a different > parser when using > castor to generate source code??? > thanks, > dean > > Ostermueller, Erik wrote: > > > > -----Original Message----- > > > From: Dean Hiller [mailto:[EMAIL PROTECTED]] > > > Sent: Friday, April 18, 2003 3:01 PM > > > To: [EMAIL PROTECTED] > > > Subject: Re: [castor-dev] jaxp / parser configuration > > > > > > > > > I did forget one thing. That only works if > one is only > > > changing the > > > parser at runtime. Then again, are there people who > > > want to change the > > > parser at build time??? > >I don't quite understand the question. Perhaps this > answers it. > >We want the flexibility to change out the parser only > when we are tweaking our system. > >I can think of two main reason: > >1) when we're tweaking performance. > >2) when we incorporate new code into the system that already > >uses an xml parser, we'll probably reevaluate which > implementation we chose. > > > >We don't have any need to switch the parser at runtime. > > > > > I have not needed to and have > > > not been doing > > > that. If there are others, we probably cannot do it > > > that way unless > > > someone else has some ideas. Does anyone need to > > > change the parser at > > > build time? > > > thanks, > > > dean > > > > > > Ostermueller, Erik wrote: > > > > > > > > "Ostermueller, Erik" wrote: > > > > > > > > > > > > Hello all, > > > > > > > > > > > > As pointed out here > > > > > > > > > http://www.mail-archive.com/[EMAIL PROTECTED]/msg13407.html, > > > > > > bugs 1216 and 1279 seem closely > related. Is anyone > > > > > actively working this? > > > > > > > > > > Not to my knowledge, though I know > Dean mentioned he > > > > > would be willing to > > > > > take shot at it if we, the Castor > community, decided > > > > > which method we > > > > > preferred. > > > >The options on the table are in this buzilla > report, yes? > > > >http://bugzilla.exolab.org/show_bug.cgi?id=1216. > > > >If so, I vote for the last one. Other opinions? > > > > > > > > > > > > > > > > > Also, I found a few other apache > classes that are > > > > > imported explicity in > > > > > > these castor classes: > > > > > > Configuration, LocalConfiguration, > Marshaller, > > > > > SchemaReader, SchemaWriter, > > > > > > XMLInstance2Schema, AnyNode, and a > number of > > > files in > > > > > the /src/examples directory. > > > > > > > > > > > > These are the apache files that are > imported: > > > > > > > > > > > > > > > http://xml.apache.org/xerces-j/apiDocs/org/apache/xml/se > > > > > rialize/Serializer.html > > > > > > > > > > > > > > > http://xml.apache.org/xerces-j/apiDocs/org/apache/xml/se > > > > > rialize/OutputFormat.html > > > > > > > > > > > > > > > http://xml.apache.org/xerces-j/apiDocs/org/apache/xml/se > > > > > rialize/Method.html > > > > > > > > > > > > Any suggestions for getting rid of these > > > three dependencies? > > > > > > > > > > I was thinking about this a while > back. We could come > > > > > up with our own > > > > > Serializer interface and then write a default > > > > > implementation > > > >in the castor package space, right? > > > > > > > > > of that > > > > > interface which uses Xerces as the underlying > > > > > serializer. > > > >So, all methods would simply delegate to the > Xerces version? > > > > > > > > > This would at > > > > > least limit the Xerces code to one > class and it could > > > > > easily be replaced > > > > > by anyone who wishes to use their own > implementation > > > > > for a different > > > > > parser pacakge. > > > >How would you suggest that we switch between > different > > > implementations? > > > >Use a factory that inspects a parameter(if > > > "Xerces".equals(serializerParm)... )? > > > >Or just use .setSerializer(new > MySerializerImpl() ) methods? > > > > > > > > > > --Keith > > > > > > > > > > > > > > ----------------------------------------------------------- > > > > > If you wish to unsubscribe from this mailing, > > > send mail to > > > > > [EMAIL PROTECTED] with a subject of: > > > > > unsubscribe castor-dev > > > > > > > > > > > > > > > DISCLAIMER: > > > > > This email message is for the sole > use of the intended > > > > > recipient(s) and may contain confidential and > > > > > privileged information. Any > unauthorized review, use, > > > > > disclosure or distribution is > prohibited. If you are > > > > > not the intended recipient, please > contact the sender > > > > > by reply email and destroy all copies > of the original > > > > > message and attachments. > > > > > > > > > > > > > >----------------------------------------------------------- > > > >If you wish to unsubscribe from this mailing, > send mail to > > > >[EMAIL PROTECTED] with a subject of: > > > > unsubscribe castor-dev > > > > > > > > > > > > > > > > > > > ----------------------------------------------------------- > > > If you wish to unsubscribe from this mailing, > send mail to > > > [EMAIL PROTECTED] with a subject of: > > > unsubscribe castor-dev > > > > > > > > > DISCLAIMER: > > > This email message is for the sole use of the intended > > > recipient(s) and may contain confidential and > > > privileged information. Any unauthorized review, use, > > > disclosure or distribution is prohibited. If you are > > > not the intended recipient, please contact the sender > > > by reply email and destroy all copies of the original > > > message and attachments. > > > > > > >----------------------------------------------------------- > >If you wish to unsubscribe from this mailing, send mail to > >[EMAIL PROTECTED] with a subject of: > > unsubscribe castor-dev > > > > > > > > ----------------------------------------------------------- > If you wish to unsubscribe from this mailing, send mail to > [EMAIL PROTECTED] with a subject of: > unsubscribe castor-dev > > > DISCLAIMER: > This email message is for the sole use of the intended > recipient(s) and may contain confidential and > privileged information. Any unauthorized review, use, > disclosure or distribution is prohibited. If you are > not the intended recipient, please contact the sender > by reply email and destroy all copies of the original > message and attachments. > ----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of: unsubscribe castor-dev----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of: unsubscribe castor-dev
DISCLAIMER:
This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message and attachments.
