1) Does ANYONE have ANY expierences with using an XSLT processor within
an EJB Server ?
My own personal experience in side-stepping the issue ;-):
Using weblogic 5.1 with Cocoon 1.7.4 successfully to combine an EJB approach
to store and model XML content and Cocoon to serve up generated html using
XML +XSLT.
System architecture:
Storing XML content in a regular RDBMS in a coarse-grained fashion, with
access provided via an entity bean and associated value object.
We use a non-EJB helper class to publish the content as an XML file to disk.
Essentially our application is read-intensive with limited updates, so we
optimize for the read case and handle writing as an exceptional case. So
the XML is published as described above to a static file on disk to be
picked up by Cocoon and "published" in whatever markup language makes sense
for the requesting user-agent via XSLT.
To answer your question, we've avoided having to tie EJB output directly to
an XSLT processor. Our main concern here was performance. We want all the
benefits of using EJB whilst minimizing exposure to the potential overhead.
Cocoon also has a cache structure which we can leverage by this design
approach.
2) What happens, if we don't deploy the processor into the AppServer,
but have the processor runing aside ?
That means: the processor is made available to an EJB via setting the
classpath, but it executes not within the Appserver.
What does this mean for the transactional context. Can we ever access
an EJB again from the processor, that runs within the
same transaction as that bean, which invoked the processor ?
Answered already.
3) Does anyone know about an XSLT-EJB to buy (as the EJB/J2EE has the
idea of a bean market) ?
No.
4) Or does anyone have information about an XSLT information base (some
links ...) ?
Not specifically related to integration with EJB? You will find useful XSLT
information at http://xml.apache.org/xalan/ and I find the XSLT Programmers
Reference from Wrox (Michael Kay) to be a good book too.
<MY QUESTION>
Now this raises a point with regard to what EJBs can and cannot do:
I should not be able to do file i/o, use classloaders, fire off worker
threads etc. within an EJB (see EJB 1.1 spec: 18.1.2 for more details) but
I can. My experience indicates that vendors don't check for these spec.
violations at ejb compilation time or runtime.
So to ask this question in a more general way, is it correct that if I know
I will be doing something which EJBs should not be allowed to do, to pull
that functionality into a non-EJB helper class? Will this approach satisfy
the specification requirements in this area for the foreseeable future
(1.1/2.0 and beyond)?
Do vendors plan to start checking these restrictions into their products any
time soon? If not, is there a reason? Do you have client feedback which
says "no way - we're breaking the spec. right now thank you very much
because we have to" or is it simply low priority?
</MY QUESTION>
Humphrey
-----Original Message-----
From: Schweighofer Wolfgang [mailto:[EMAIL PROTECTED]]
Sent: 21 July 2000 10:21
To: [EMAIL PROTECTED]
Subject: XSLT Processor & EJB
Hi,
we want to use an XSLT Processor (say XALAN by AlphaWorX or XT by James
Clark) within an EJB AppServer (say IONA iPAS).
The first thing was to deploy the processor into an EJB (600 classes),
which worked after a while.
Then we had some trial runs, which seemed to work, until we tried to
call a Java class from within the XSLT code
(in fact we tried the demo codes shipped with the XALAN processor), but
it wouldn't work.
The AppServer always generates marshaling or null pointer exceptions in
an arbitrary way.
When we had a closer look at the EJB Spec and the processor, we saw
that:
1) classloaders are not alowed within EJB, but the processor uses it
(has to use it, as it instantiates classes, known to him only as
strings in the XSLT code)
2) streams are not allowed within EJB, but the processor uses it (only
for intern handling but not for File IO-operations)
3) don't know what else happens in the 600 classes of the processor...
Question:
1) Does ANYONE have ANY expierences with using an XSLT processor within
an EJB Server ?
2) What happens, if we don't deploy the processor into the AppServer,
but have the processor runing aside ?
That means: the processor is made available to an EJB via setting the
classpath, but it executes not within the Appserver.
What does this mean for the transactional context. Can we ever access
an EJB again from the processor, that runs within the
same transaction as that bean, which invoked the processor ?
3) Does anyone know about an XSLT-EJB to buy (as the EJB/J2EE has the
idea of a bean market) ?
4) Or does anyone have information about an XSLT information base (some
links ...) ?
ANY help would be appreciated, so please, if you have an idea, just give
me some lines...
Many thanks
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
DI Wolfgang Schweighofer
Austria Telecommunication
eMail: [EMAIL PROTECTED]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
