You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Kris Schneider <kr...@dotech.com> on 2003/01/16 22:12:36 UTC
Struts app design for multiple client types
I'm in the process of designing a single web app to support two different client
types: HTML and VoiceXML. Yes, yes, I know, XSLT is just the ticket. That was my
initial take at least, but I'd like to bounce some things off the Struts hive
before committing to it. To add some context, I'll be deploying on a full J2EE
1.3 platform, so things like servlet filters and JSTL get to play. I'm also
aware of existing XML/XSLT solutions like Cocoon, stxx, and StrutsCX and have
done some preliminary investigation of each. The application itself is generally
form/data driven. The major issues I'm currently spinning on are the following:
What do the existing solutions offer that I couldn't do with JSTL and relatively
simple filters? For instance, my JSPs might just become:
<x:transform xslt="${dynamicallyAssignedBasedOnUserAgent}">
<!-- body specifies XML document and transform params -->
</x:transform>
How difficult would it be to duplicate the functionality of the Struts html and
nested tags? Those tags do a lot of work on a page author's behalf with respect
to handling form rendering, indexed form bean properties, transaction tokens,
URL encoding, etc. If the app is just dumping XML, then it seems like the XSLT
styleheets could get pretty hairy. I suppose the Struts tags could still be used
to output XHTML fragments which might make the transforms less painful.
If you've got some specific insight into those issues, or would just like to
share your approach to using Struts for apps that support multiple client types,
I'd love to hear about it. Thanks.
--
Kris Schneider <ma...@dotech.com>
D.O.Tech <http://www.dotech.com/>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Struts app design for multiple client types
Posted by Kris Schneider <kr...@dotech.com>.
Thanks for tip, I took a quick look. I have to say the first example
made my head spin.
http://home.attbi.com/~danjacobs/jplates.com/examples/test/ClassInfo1.jplate
It just doesn't look like the kind of approach that would appeal to the
no-scriptlet faithful (which is where I firmly plant myself). Of course,
I didn't get much beyond the example, but I'm not too inclined to keep
investigating at his point. The front page of the site sounds great
though...
Dan Jacobs wrote:
> Hi Kris,
>
> Unless your application data starts off as XML in the first place, and
> assuming you're a Java programmer, I recommend using JPlates
> (http://www.jplates.com) for multi-target transformations. JPlates is a
> fully object-oriented template language, and I've used it very
> sucessfully both for generating HTML and for transforming XML.
>
> -- Dan
>
> Kris Schneider wrote:
>
>> I'm in the process of designing a single web app to support two
>> different client
>> types: HTML and VoiceXML. Yes, yes, I know, XSLT is just the ticket.
>> That was my
>> initial take at least, but I'd like to bounce some things off the
>> Struts hive
>> before committing to it. To add some context, I'll be deploying on a
>> full J2EE
>> 1.3 platform, so things like servlet filters and JSTL get to play. I'm
>> also
>> aware of existing XML/XSLT solutions like Cocoon, stxx, and StrutsCX
>> and have
>> done some preliminary investigation of each. The application itself is
>> generally
>> form/data driven. The major issues I'm currently spinning on are the
>> following:
>>
>> What do the existing solutions offer that I couldn't do with JSTL and
>> relatively
>> simple filters? For instance, my JSPs might just become:
>>
>> <x:transform xslt="${dynamicallyAssignedBasedOnUserAgent}">
>> <!-- body specifies XML document and transform params -->
>> </x:transform>
>>
>> How difficult would it be to duplicate the functionality of the Struts
>> html and
>> nested tags? Those tags do a lot of work on a page author's behalf
>> with respect
>> to handling form rendering, indexed form bean properties, transaction
>> tokens,
>> URL encoding, etc. If the app is just dumping XML, then it seems like
>> the XSLT
>> styleheets could get pretty hairy. I suppose the Struts tags could
>> still be used
>> to output XHTML fragments which might make the transforms less painful.
>>
>> If you've got some specific insight into those issues, or would just
>> like to
>> share your approach to using Struts for apps that support multiple
>> client types,
>> I'd love to hear about it. Thanks.
>>
>
>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
--
Kris Schneider <ma...@dotech.com>
D.O.Tech <http://www.dotech.com/>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Struts app design for multiple client types
Posted by Dan Jacobs <dj...@modelobjects.com>.
Hi Kris,
Unless your application data starts off as XML in the first place, and
assuming you're a Java programmer, I recommend using JPlates
(http://www.jplates.com) for multi-target transformations. JPlates is a
fully object-oriented template language, and I've used it very
sucessfully both for generating HTML and for transforming XML.
-- Dan
Kris Schneider wrote:
>I'm in the process of designing a single web app to support two different client
>types: HTML and VoiceXML. Yes, yes, I know, XSLT is just the ticket. That was my
>initial take at least, but I'd like to bounce some things off the Struts hive
>before committing to it. To add some context, I'll be deploying on a full J2EE
>1.3 platform, so things like servlet filters and JSTL get to play. I'm also
>aware of existing XML/XSLT solutions like Cocoon, stxx, and StrutsCX and have
>done some preliminary investigation of each. The application itself is generally
>form/data driven. The major issues I'm currently spinning on are the following:
>
>What do the existing solutions offer that I couldn't do with JSTL and relatively
>simple filters? For instance, my JSPs might just become:
>
><x:transform xslt="${dynamicallyAssignedBasedOnUserAgent}">
> <!-- body specifies XML document and transform params -->
></x:transform>
>
>How difficult would it be to duplicate the functionality of the Struts html and
>nested tags? Those tags do a lot of work on a page author's behalf with respect
>to handling form rendering, indexed form bean properties, transaction tokens,
>URL encoding, etc. If the app is just dumping XML, then it seems like the XSLT
>styleheets could get pretty hairy. I suppose the Struts tags could still be used
>to output XHTML fragments which might make the transforms less painful.
>
>If you've got some specific insight into those issues, or would just like to
>share your approach to using Struts for apps that support multiple client types,
>I'd love to hear about it. Thanks.
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Struts app design for multiple client types
Posted by Jacob Hookom <ho...@uwec.edu>.
| -----Original Message-----
| From: Kris Schneider [mailto:kris@dotech.com]
| Sent: Thursday, January 16, 2003 3:58 PM
| To: Struts Users Mailing List
| Subject: RE: Struts app design for multiple client types
|
| Any take on having the filter perform the transform vs. JSTL (see
original
| example)? Seems like you ought to be able to work up a caching
approach
| with
| JSTL as well.
|
| How 'bout the fact that by creating XML you give up some of the Struts
| tags?
The only tags I use are the form tags. Even if you are using the form
tags in generating XML data for transformation, you can take XSL from an
XHTML formatted form tag and do an <xsl:copy> to manipulate or duplicate
the xml output.
|
| Quoting Jacob Hookom <ho...@uwec.edu>:
|
| > If you are dealing with two platforms, I would say use filters.
Request
| > processes would go like such:
| >
| > www.mysite.com/public/viewAll.html
| > -->Filter catches request, wraps the response and forwards to:
| > www.mysite.com/viewAll.do?format=html&forward=xml
| > -->Struts generates beans and forwards to JSP for XML generation
| > www.mysite.com/WEB-INF/transform.jsp?format=html
| > -->Page outputs XML data, but remember the filter gets the response
back
| > so it then looks at the format again or another request attribute to
get
| > the style sheet to do the transformation and setting of the headers.
| >
| > So your Struts actions know nothing of what formatting to use or
what
| > XML is, they just get the business objects you need based on the
| > request. Then your action can possibly check for the forward tag to
| > actually forward to a JSP that will take the output and create XML.
| > Then it is up to your filter to catch the returning response and do
an
| > XSLT transformation on it and set the appropriate headers. This
output
| > can be cached for faster access next time.
| >
| > Jacob Hookom
| >
| > | -----Original Message-----
| > | From: Kris Schneider [mailto:kris@dotech.com]
| > | Sent: Thursday, January 16, 2003 3:13 PM
| > | To: Struts Users Mailing List
| > | Subject: Struts app design for multiple client types
| > |
| > | I'm in the process of designing a single web app to support two
| > different
| > | client
| > | types: HTML and VoiceXML. Yes, yes, I know, XSLT is just the
ticket.
| > That
| > | was my
| > | initial take at least, but I'd like to bounce some things off the
| > Struts
| > | hive
| > | before committing to it. To add some context, I'll be deploying on
a
| > full
| > | J2EE
| > | 1.3 platform, so things like servlet filters and JSTL get to play.
I'm
| > | also
| > | aware of existing XML/XSLT solutions like Cocoon, stxx, and
StrutsCX
| > and
| > | have
| > | done some preliminary investigation of each. The application
itself is
| > | generally
| > | form/data driven. The major issues I'm currently spinning on are
the
| > | following:
| > |
| > | What do the existing solutions offer that I couldn't do with JSTL
and
| > | relatively
| > | simple filters? For instance, my JSPs might just become:
| > |
| > | <x:transform xslt="${dynamicallyAssignedBasedOnUserAgent}">
| > | <!-- body specifies XML document and transform params -->
| > | </x:transform>
| > |
| > | How difficult would it be to duplicate the functionality of the
Struts
| > | html and
| > | nested tags? Those tags do a lot of work on a page author's behalf
| > with
| > | respect
| > | to handling form rendering, indexed form bean properties,
transaction
| > | tokens,
| > | URL encoding, etc. If the app is just dumping XML, then it seems
like
| > the
| > | XSLT
| > | styleheets could get pretty hairy. I suppose the Struts tags could
| > still
| > | be used
| > | to output XHTML fragments which might make the transforms less
| > painful.
| > |
| > | If you've got some specific insight into those issues, or would
just
| > like
| > | to
| > | share your approach to using Struts for apps that support multiple
| > client
| > | types,
| > | I'd love to hear about it. Thanks.
| > |
| > | --
| > | Kris Schneider <ma...@dotech.com>
| > | D.O.Tech <http://www.dotech.com/>
| > |
| > | --
| > | To unsubscribe, e-mail: <mailto:struts-user-
| > | unsubscribe@jakarta.apache.org>
| > | For additional commands, e-mail: <mailto:struts-user-
| > | help@jakarta.apache.org>
| >
| >
| > --
| > To unsubscribe, e-mail:
| > <ma...@jakarta.apache.org>
| > For additional commands, e-mail:
| > <ma...@jakarta.apache.org>
| >
|
|
| --
| Kris Schneider <ma...@dotech.com>
| D.O.Tech <http://www.dotech.com/>
|
| --
| To unsubscribe, e-mail: <mailto:struts-user-
| unsubscribe@jakarta.apache.org>
| For additional commands, e-mail: <mailto:struts-user-
| help@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Struts app design for multiple client types
Posted by Kris Schneider <kr...@dotech.com>.
Any take on having the filter perform the transform vs. JSTL (see original
example)? Seems like you ought to be able to work up a caching approach with
JSTL as well.
How 'bout the fact that by creating XML you give up some of the Struts tags?
Quoting Jacob Hookom <ho...@uwec.edu>:
> If you are dealing with two platforms, I would say use filters. Request
> processes would go like such:
>
> www.mysite.com/public/viewAll.html
> -->Filter catches request, wraps the response and forwards to:
> www.mysite.com/viewAll.do?format=html&forward=xml
> -->Struts generates beans and forwards to JSP for XML generation
> www.mysite.com/WEB-INF/transform.jsp?format=html
> -->Page outputs XML data, but remember the filter gets the response back
> so it then looks at the format again or another request attribute to get
> the style sheet to do the transformation and setting of the headers.
>
> So your Struts actions know nothing of what formatting to use or what
> XML is, they just get the business objects you need based on the
> request. Then your action can possibly check for the forward tag to
> actually forward to a JSP that will take the output and create XML.
> Then it is up to your filter to catch the returning response and do an
> XSLT transformation on it and set the appropriate headers. This output
> can be cached for faster access next time.
>
> Jacob Hookom
>
> | -----Original Message-----
> | From: Kris Schneider [mailto:kris@dotech.com]
> | Sent: Thursday, January 16, 2003 3:13 PM
> | To: Struts Users Mailing List
> | Subject: Struts app design for multiple client types
> |
> | I'm in the process of designing a single web app to support two
> different
> | client
> | types: HTML and VoiceXML. Yes, yes, I know, XSLT is just the ticket.
> That
> | was my
> | initial take at least, but I'd like to bounce some things off the
> Struts
> | hive
> | before committing to it. To add some context, I'll be deploying on a
> full
> | J2EE
> | 1.3 platform, so things like servlet filters and JSTL get to play. I'm
> | also
> | aware of existing XML/XSLT solutions like Cocoon, stxx, and StrutsCX
> and
> | have
> | done some preliminary investigation of each. The application itself is
> | generally
> | form/data driven. The major issues I'm currently spinning on are the
> | following:
> |
> | What do the existing solutions offer that I couldn't do with JSTL and
> | relatively
> | simple filters? For instance, my JSPs might just become:
> |
> | <x:transform xslt="${dynamicallyAssignedBasedOnUserAgent}">
> | <!-- body specifies XML document and transform params -->
> | </x:transform>
> |
> | How difficult would it be to duplicate the functionality of the Struts
> | html and
> | nested tags? Those tags do a lot of work on a page author's behalf
> with
> | respect
> | to handling form rendering, indexed form bean properties, transaction
> | tokens,
> | URL encoding, etc. If the app is just dumping XML, then it seems like
> the
> | XSLT
> | styleheets could get pretty hairy. I suppose the Struts tags could
> still
> | be used
> | to output XHTML fragments which might make the transforms less
> painful.
> |
> | If you've got some specific insight into those issues, or would just
> like
> | to
> | share your approach to using Struts for apps that support multiple
> client
> | types,
> | I'd love to hear about it. Thanks.
> |
> | --
> | Kris Schneider <ma...@dotech.com>
> | D.O.Tech <http://www.dotech.com/>
> |
> | --
> | To unsubscribe, e-mail: <mailto:struts-user-
> | unsubscribe@jakarta.apache.org>
> | For additional commands, e-mail: <mailto:struts-user-
> | help@jakarta.apache.org>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
Kris Schneider <ma...@dotech.com>
D.O.Tech <http://www.dotech.com/>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Struts app design for multiple client types
Posted by Jacob Hookom <ho...@uwec.edu>.
If you are dealing with two platforms, I would say use filters. Request
processes would go like such:
www.mysite.com/public/viewAll.html
-->Filter catches request, wraps the response and forwards to:
www.mysite.com/viewAll.do?format=html&forward=xml
-->Struts generates beans and forwards to JSP for XML generation
www.mysite.com/WEB-INF/transform.jsp?format=html
-->Page outputs XML data, but remember the filter gets the response back
so it then looks at the format again or another request attribute to get
the style sheet to do the transformation and setting of the headers.
So your Struts actions know nothing of what formatting to use or what
XML is, they just get the business objects you need based on the
request. Then your action can possibly check for the forward tag to
actually forward to a JSP that will take the output and create XML.
Then it is up to your filter to catch the returning response and do an
XSLT transformation on it and set the appropriate headers. This output
can be cached for faster access next time.
Jacob Hookom
| -----Original Message-----
| From: Kris Schneider [mailto:kris@dotech.com]
| Sent: Thursday, January 16, 2003 3:13 PM
| To: Struts Users Mailing List
| Subject: Struts app design for multiple client types
|
| I'm in the process of designing a single web app to support two
different
| client
| types: HTML and VoiceXML. Yes, yes, I know, XSLT is just the ticket.
That
| was my
| initial take at least, but I'd like to bounce some things off the
Struts
| hive
| before committing to it. To add some context, I'll be deploying on a
full
| J2EE
| 1.3 platform, so things like servlet filters and JSTL get to play. I'm
| also
| aware of existing XML/XSLT solutions like Cocoon, stxx, and StrutsCX
and
| have
| done some preliminary investigation of each. The application itself is
| generally
| form/data driven. The major issues I'm currently spinning on are the
| following:
|
| What do the existing solutions offer that I couldn't do with JSTL and
| relatively
| simple filters? For instance, my JSPs might just become:
|
| <x:transform xslt="${dynamicallyAssignedBasedOnUserAgent}">
| <!-- body specifies XML document and transform params -->
| </x:transform>
|
| How difficult would it be to duplicate the functionality of the Struts
| html and
| nested tags? Those tags do a lot of work on a page author's behalf
with
| respect
| to handling form rendering, indexed form bean properties, transaction
| tokens,
| URL encoding, etc. If the app is just dumping XML, then it seems like
the
| XSLT
| styleheets could get pretty hairy. I suppose the Struts tags could
still
| be used
| to output XHTML fragments which might make the transforms less
painful.
|
| If you've got some specific insight into those issues, or would just
like
| to
| share your approach to using Struts for apps that support multiple
client
| types,
| I'd love to hear about it. Thanks.
|
| --
| Kris Schneider <ma...@dotech.com>
| D.O.Tech <http://www.dotech.com/>
|
| --
| To unsubscribe, e-mail: <mailto:struts-user-
| unsubscribe@jakarta.apache.org>
| For additional commands, e-mail: <mailto:struts-user-
| help@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Struts app design for multiple client types
Posted by Kris Schneider <kr...@dotech.com>.
Inline...
Quoting "Craig R. McClanahan" <cr...@apache.org>:
>
>
> On Thu, 16 Jan 2003, Kris Schneider wrote:
>
> > Date: Thu, 16 Jan 2003 16:12:36 -0500
> > From: Kris Schneider <kr...@dotech.com>
> > Reply-To: Struts Users Mailing List <st...@jakarta.apache.org>
> > To: Struts Users Mailing List <st...@jakarta.apache.org>
> > Subject: Struts app design for multiple client types
> >
> > I'm in the process of designing a single web app to support two different
> client
> > types: HTML and VoiceXML. Yes, yes, I know, XSLT is just the ticket. That
> was my
> > initial take at least, but I'd like to bounce some things off the Struts
> hive
> > before committing to it. To add some context, I'll be deploying on a full
> J2EE
> > 1.3 platform, so things like servlet filters and JSTL get to play. I'm
> also
> > aware of existing XML/XSLT solutions like Cocoon, stxx, and StrutsCX and
> have
> > done some preliminary investigation of each. The application itself is
> generally
> > form/data driven. The major issues I'm currently spinning on are the
> following:
> >
> > What do the existing solutions offer that I couldn't do with JSTL and
> relatively
> > simple filters? For instance, my JSPs might just become:
> >
> > <x:transform xslt="${dynamicallyAssignedBasedOnUserAgent}">
> > <!-- body specifies XML document and transform params -->
> > </x:transform>
> >
> > How difficult would it be to duplicate the functionality of the Struts html
> and
> > nested tags? Those tags do a lot of work on a page author's behalf with
> respect
> > to handling form rendering, indexed form bean properties, transaction
> tokens,
> > URL encoding, etc. If the app is just dumping XML, then it seems like the
> XSLT
> > styleheets could get pretty hairy. I suppose the Struts tags could still be
> used
> > to output XHTML fragments which might make the transforms less painful.
> >
>
> Why would it be necessary to add XSLT functionality to Struts tags, when
> the <x:transform> tag already exists. Or, to put it another way, what
> does the <x:transform> tag (by itself) *not* do that you think would be
> helpful?
>
Communication breakdown there - not at all what I intended to convey. One of my
concerens is that if I move to an architecture where the app outputs XML that is
then transformed, I lose the built-in functionality of the HTML-centric Struts
tags like html and nested. Presumably, that functionality (e.g. rendering form
elements for indexed form bean properties, tokens, etc.) would have to be
handled by the XSLT stylesheets. One of the potential compromises is to use the
Struts tags to output XHTML to generically represent forms and links. So, I
don't have any problems with the Struts tags, just the opposite, I'm concerned
about losing their utility by moving to a more XML-centric approach.
As for the <x:transform> tag, I'm actually thinking that it might obviate the
need for additional add-ons like stxx and StrutsCX. I can have an action forward
to a JSP for the client-agnostic view (i.e. XML) by using something like my
original example. Since <x:transform> can take a dynamic value for the XSLT
stylesheet, it seems like a pretty flexible solution.
> My gut feel is that further XMLish integration into Struts itself should
> focus more on things like defining a processing pipeline in struts-config
> -- sort of like Cocoon's sitemap, but not quite so much work. In other
> words, focus on enriching the controller functionality.
>
+1
> Tag libraries like JSTL are designed to interoperate with each other, so
> if you happen to be using JSP for output, it makes perfect sense (at least
> to me) to use them.
>
> > If you've got some specific insight into those issues, or would just like
> to
> > share your approach to using Struts for apps that support multiple client
> types,
> > I'd love to hear about it. Thanks.
> >
> > --
> > Kris Schneider <ma...@dotech.com>
> > D.O.Tech <http://www.dotech.com/>
>
> Craig
>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
Kris Schneider <ma...@dotech.com>
D.O.Tech <http://www.dotech.com/>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Struts app design for multiple client types
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Thu, 16 Jan 2003, Kris Schneider wrote:
> Date: Thu, 16 Jan 2003 16:12:36 -0500
> From: Kris Schneider <kr...@dotech.com>
> Reply-To: Struts Users Mailing List <st...@jakarta.apache.org>
> To: Struts Users Mailing List <st...@jakarta.apache.org>
> Subject: Struts app design for multiple client types
>
> I'm in the process of designing a single web app to support two different client
> types: HTML and VoiceXML. Yes, yes, I know, XSLT is just the ticket. That was my
> initial take at least, but I'd like to bounce some things off the Struts hive
> before committing to it. To add some context, I'll be deploying on a full J2EE
> 1.3 platform, so things like servlet filters and JSTL get to play. I'm also
> aware of existing XML/XSLT solutions like Cocoon, stxx, and StrutsCX and have
> done some preliminary investigation of each. The application itself is generally
> form/data driven. The major issues I'm currently spinning on are the following:
>
> What do the existing solutions offer that I couldn't do with JSTL and relatively
> simple filters? For instance, my JSPs might just become:
>
> <x:transform xslt="${dynamicallyAssignedBasedOnUserAgent}">
> <!-- body specifies XML document and transform params -->
> </x:transform>
>
> How difficult would it be to duplicate the functionality of the Struts html and
> nested tags? Those tags do a lot of work on a page author's behalf with respect
> to handling form rendering, indexed form bean properties, transaction tokens,
> URL encoding, etc. If the app is just dumping XML, then it seems like the XSLT
> styleheets could get pretty hairy. I suppose the Struts tags could still be used
> to output XHTML fragments which might make the transforms less painful.
>
Why would it be necessary to add XSLT functionality to Struts tags, when
the <x:transform> tag already exists. Or, to put it another way, what
does the <x:transform> tag (by itself) *not* do that you think would be
helpful?
My gut feel is that further XMLish integration into Struts itself should
focus more on things like defining a processing pipeline in struts-config
-- sort of like Cocoon's sitemap, but not quite so much work. In other
words, focus on enriching the controller functionality.
Tag libraries like JSTL are designed to interoperate with each other, so
if you happen to be using JSP for output, it makes perfect sense (at least
to me) to use them.
> If you've got some specific insight into those issues, or would just like to
> share your approach to using Struts for apps that support multiple client types,
> I'd love to hear about it. Thanks.
>
> --
> Kris Schneider <ma...@dotech.com>
> D.O.Tech <http://www.dotech.com/>
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>