commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <>
Subject Re: Jelly and X++
Date Mon, 10 Feb 2003 19:41:01 GMT
From: "Bryan Field-Elliot" <>
> On Sat, 2003-02-08 at 10:00, Paul Libbrecht wrote:
>     You forgot one essential thing in there: Jelly can contain explicit
>     XML
>     content making it more than appropriate for elementary
>     XML-file-based
>     data processing.
>     Such elementary thing as merging before handing to a stylesheet and
>     still processing its output with  a bit more scripting is something
>     that I have only seen at other places in ten times more verbose
>     ways.
> I imagine this is the kind of statement which would take me a month of
> working with Jelly to fully appreciate.


A Jelly script is a piece of XML that gets parsed in to a Script object that
can be cached and reused across threads. When the script runs, it outputs
SAX events. This XML can contain dynamic expressions (say XPath or Jexl or
JavaScript or whatnot) as well as truly dynamic blocks of code (tags, beans,
real scripting language blocks etc). The nice bit about this is the XML (or
SAX events) get cached, so at runtime there's no need to parse the XML
inside the Jelly script.

Also each Jelly tag can process variables (beans, DOM fragments, text) or
filter and pipeline XML events (SAX) so all kinds of processing models and
pipelining mechanisms can be supported.

So Jelly is great for generating dynamic XML, parsing, processing or
filtering XML and pipelining into other processors (like SOAP servers, XSLT
engines etc).

So its easy to mix and match working with SAX, DOM, XPath, XSLT, JARV,
beans, SOAP etc. Plugging in JAXB where it makes sense would be pretty easy

> My interest in these tools is not so much in "a language which can be
> fully expressed in XML", but rather, "a language which gives me great
> XML parsing, transforming, and business logic delegation capabilities",
> something which I am dissatisfied with given the current crop of
> Java/XML data binding tools.

I think Jelly might help in the latter right now. e.g. there's tools for
XSLT, XPath, parsing HTML and implementing SAX filters & SOAP calls.

SOAP support is probably Jelly's weakest area right now. e.g. it might be
cool to implement a JROM library for working with typesafe XML in an
efficient generic structure.

> What I need is to receive XML docs (usually via SOAP), tear them apart,
> delegate business logic, and assemble responses (also XML docs), to send
> back out over the wire again.
> What dissatisfies me with the current crop of Java/XML data binding
> tools (including Castor and JAXB), is the awkwardness with which you
> have to deal with type extensions (<xsi:type>), where the original code
> might know very well the base type, but not the extended type it's being
> thrown at runtime. In this scenario, I'd like as lightweight-way as
> possible to add business logic, without having to rebuild the whole
> project from source, to deal with new types on an ongoing basis.
> Castor/JAXB, etc take the approach that, "if you don't know the Schema
> at compile time, then we can't deal with it, so go back to DOM". (Not to
> disparage Castor, it's great in a whole of other ways).
> Sounds like Jelly may be what I need?

Its certainly got most of what you need. Probably the biggest missing part
in your example is a SAX based 'pull a SOAP envelope apart and process with
seperate business logic' piece.

e.g. its been on the to do list for a while

to try add a STX library (thats like XSLT but works purely on SAX streams)
while allowing Jelly tags to be invoked within the STX transformation - this
could be good for splitting your SOAP message up into pieces. e.g. Joost is
an STX implementation...

Another approach could be just to use DOM, JROM or Castor/JAXB. The nice
thing about having STX support (or your own custom SAX filter logic) would
be that you could mix SOAP + SAX filters + any combination of (DOM / JROM /
Castor / JAXB, beans etc)

i.e. a single SOAP message could be split up into multiple parts, each part
could be processed in a different way (e.g. one part use JAXB, one part use
DOM, one part use SAX based XSLT, one using beans, one invoking an EJB etc).


Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts

View raw message