My first contact with StrutsCX

Hello there.

I'm implementing StrutsCX in a prototype/small project in order to validate
StrutsCX framework.
My first impression is good, StrutsCX framework is small (ie, not a bunch of
"heavy" jars) and simple to use (excellent & straightforward installation
guide).

However, if have a few comments about DocumentBuilder & Transformer. I have
implemented my own classes in order to perform some tasks which were missing
in the ones delivered. Fortunately, as StrutsCX can be configured to
change/choose our own DocumentBuilder & Transformer classes, this has been
easy.

I wanted to perform/correct the following :

. DocumentBuilder (aka
com.cappuccinonet.strutscx.xslt.StrutsCXStandardDocumentBuilder)
============================================================================
===========

In fact my changes did not impact this class but the
com.cappuccinonet.strutscx.xslt.StrutsCXBeanToElement class.
We have been using Castor framework for a while now. I have been quite
surprised to realize that the StrutsCXBeanToElement class did not
serialize/marshall my objets the same way Castor would (letter case,
attributes, etc.). What I did is to overload the "private Element
checkBeanContent(Object bean)" method with :

***********************************************************
private Element checkBeanContent(Object bean)	throws
IntrospectionException, IllegalAccessException, InvocationTargetException,
MarshalException, ParserConfigurationException, ValidationException
	{
		org.w3c.dom.Document dom =
javax.xml.parsers.DocumentBuilderFactory.newInstance().newDocumentBuilder().
newDocument();
		org.exolab.castor.xml.Marshaller.marshal(bean, dom);
				
		return new
org.jdom.input.DOMBuilder().build(dom).detachRootElement();
	}
***********************************************************

And off course I setted the strutscx-config.xml file properly. This works
great.

Maybe I missed something, but this behaviour (using Castor's Marshalling
way) should be natively present inside StrutsCX IMHO.


. Transformer (aka
com.cappuccinonet.strutscx.xslt.StrutsCXStandardTransformer)
============================================================================
===

Two "problems" for this one but both refers to files URI resolving issue.

a) <!DOCTYPE xsl:stylesheet SYSTEM "entities.dtd"> inside my XSL

In order to use &nbsp; and other entites in my XSL I include a dtd reference
which declare those entities.
The XSLT engine (at least Xalan) do not use the URIResolver to find out the
dtd file.
Actually I had the following error : "could not find the file c:/document &
settings/Toto/Temporary/entities.dtd".
The path is resolved against the user.dir directory. In order to get rid of
this issue I implemented my own Transformer
(which extends StrutsCXStandardTransformer) which sets SystemId to the XSL
Source.

In method "protected Templates createXSLTemplate" :
[...]
logger.info("XSL File has changed: reparsing...!");
StreamSource ss = new StreamSource(urlConn.getInputStream());

ss.setSystemId(url.toString()); // <====== this is the "magic" line to add

xslTemplate = tFactory.newTemplates(ss);
[...]

b) <xsl:include href="toto.xsl" /> & <xsl:import href="toto.xsl" />

I could not successfully import/include xsl tree inside my XSL with such
statements. The URI could not be resolved and I had an error stating
that the file could not be found.

NOTE 1 : the @href is relative (e.g. : "toto.xsl")
NOTE 2 : my XSL files are inside /WEB-INF/xsl

So I created my own URIResolver (source code is appended at the end for
readibility sake). Works with JDK1.4+ (I use the java.net.URI class).



I wanted to contribute to the community this way.
Keep the good job.

Sincerely.

Bertrand.


****************************************************************************
****************************
package fr.bmartel.strutscx.xslt;

import java.io.IOException;
import java.net.MalformedURLException;
import java.net.URI;
import java.net.URISyntaxException;
import java.net.URL;
import java.net.URLConnection;

import javax.xml.transform.Source;
import javax.xml.transform.TransformerException;
import javax.xml.transform.URIResolver;
import javax.xml.transform.stream.StreamSource;

import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;

public class StrutsCXURIResolver implements URIResolver
{
  /**
   * The Logger we use to log JDK 1.4 conform.
   */
  protected Log logger = LogFactory.getLog(this.getClass());
	
  /**
   * The document root we will sent to the Constructor
   */
  public URI documentRoot;

  /**
   * Creates a new URIResolverImpl.
   *
   * @param documentRoot the path to the Server root which is used to
'resolve' the URI
   * @param servlet the ServletConfig we do need to create the URLConnection
on the Server
   */
  public StrutsCXURIResolver(URI documentRoot)
  {
    this.documentRoot = documentRoot;
  }

  /**
   * This is called automatically from the Transformer. 
   *
   * @param href expects a URL relative to the webapplication root starting
with "/"
   * @param base
   */
  public Source resolve(String href, String base) throws
TransformerException
  {
		URL url = null;
    try
    {
			URI hrefURI = new URI(href);
			url = this.documentRoot.resolve(hrefURI).toURL();

      if (url == null)
      {
				throw new TransformerException("Could not
resolve resource " + href);
      }
      else
      {
        URLConnection urlConn = url.openConnection();
        urlConn.connect();
        return new StreamSource(urlConn.getInputStream());
      }
    }
    catch (MalformedURLException e)
    {
      logger.error("MalformedURLException with href string " +
url.toString() + ": " + e);
      throw new TransformerException(e);
    }
    catch (IOException e)
    {
      logger.error("Could not connect to " + url.toString() + ": " + e);
      throw new TransformerException(e);
    }
		catch (URISyntaxException e)
		{
			logger.error("Could not connect to " +
url.toString() + ": " + e);
			throw new TransformerException(e);
		}
  }
}
****************************************************************************
****************************



-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn