When i link Xalan libraries with my source, i get the following error

i am using xalan version 1.2

Undefined symbol
First referenced in
XSLTInputSource::XSLTInputSource(basic_istream<char, char_traits<char>>*)
sa_xmlmsg_formatter.o
ios_base::Init::Init(void)              svrinit.o
ios_base::Init::~Init(void)              svrinit.o

Let me attach the code piece

        1) int theResult = 0;

        2) istrstream   theXSLStream(TemplateMessage,
strlen(TemplateMessage));

        3) theResult =
theXalanTransformer.compileStylesheet(&theXSLStream, theCompiledStylesheet)
;


if i comment line no 3, the first error is gone.


Can anyone help me with this?

Thanks
Arun


-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Monday, January 28, 2002 3:54 PM
To: [email protected]
Subject: Re: Livecycle of Xalan documents (fragments) and nodes



Hi Dave!

Many thanks for your reply. It provides a lot of useful hints where to look
at
and what to try :-)

> There is a great deal of documentation that goes along with the APIs.  I
> encourage you to read it, and give us feedback on whether or not it's
> clear.  You should also consider the source code as part of the
> documentation -- if you don't use it, you're giving up one of the major
> benefits of using open source software.

That's right, but it's hard to get a grip on everything all at once. There
are
so many classes and you have to check quite a lot of cross-references to
find 
your way through... But I think I'll finally manage this challenge :-)

> As far as what the most appropriate result for your tranformation --
that's
> a difficult question, since you've not really given any detail about what
> "further processing" will do.  

Basically I'm about to implement some kind of workflow mechanism to allow
data 
producers of arbitrary type to create information in XML format from
different 
data channels (e.g. NT EventLog, SNMP Traps, log file entries, ...) and
process
this data. A processor could just transform incoming data into another XML 
format and forward it to the next component, lookup other data, send an
email 
to a technician, ...

At first I wanted a producer to create a DOM tree, put it in a queue and 
forget about it (from the producers point of view). A processor connected to

the queue would than fetch the DOM tree, perform some processing (e.g. XSL 
transformation) and forward it to the next queue. So I would have to create
a
document and destroy it, when it's no longer needed by the last component in

the chain.

> Serialized XML is usually the fastest to generate, but may be inefficient 
> if you will do more DOM manipulation later on. If you're planning on a
chain 
> of XSLT transformations, and you will not need to modify the intermediate 
> results, then you can use an instance of Xalan's source tree as a target, 
> which will give you the most efficient input for the next transform.  
> Otherwise, you should probably use DOM, although it will be much, much 
> slower.  Often, it's faster to generate serialized XML and parse the
result 
> back into a DOM instance.  

Tonight I've been looking at Cocoon's approach, which is to chain data 
generators, transformers, and serializers together with SAX events. This 
approach seems to be quite good as I only need to create a complete document

whenever a component needs a complete document for its processing, e.g. for 
a transformation performed by Xalan. 

Anyway, thanks a lot for your help!
Cheers


Wolfgang

-- 
Wolfgang Schell
[EMAIL PROTECTED]

GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net

Reply via email to