RE: Strutscx-user digest, Vol 1 #108 - 1 msg
"Mohammed Dessouky" <[email protected]>
| Newsgroups | gmane.comp.java.strutscx.user |
|---|---|
| Message-ID | <D1CA422ED0E2A34DA4BF6CD6CB39FA7C45C3FB@exchsrv.versa.versasys.com> |
That's interesting that someone else also modified the framework to marshal with castor, because we did the same thing. The original reason behind trying to fit castor in the strutscx-framework was that some types were not converting to XML like if we ever passed an array or ArrayList of Strings as the StrutsCXConstants.XML_KEY. We just assumed castor would convert any daya type since it was a proven and widely used marshalling/unmarshalling mechanism. There are also added benefits that castor provides like the mapping file which gives much more control on the XML presentation as well as seperates the Java Object from the XML. Besides, doesn't the "C" in "StrutsCX" stand for Castor ? :) Would love to hear more opinions on this. Regards, Mohammed -----Original Message----- From: [email protected] [mailto:[email protected]] Sent: Monday, January 19, 2004 11:03 PM To: [email protected] Subject: Strutscx-user digest, Vol 1 #108 - 1 msg Send Strutscx-user mailing list submissions to [email protected] To subscribe or unsubscribe via the World Wide Web, visit https://lists.sourceforge.net/lists/listinfo/strutscx-user or, via email, send a message with subject or body 'help' to [email protected] You can reach the person managing the list at [email protected] When replying, please edit your Subject line so it is more specific than "Re: Contents of Strutscx-user digest..." Today's Topics: 1. AW: [Strutscx-user] My first contact with StrutsCX (Bernhard Woehrlin) --__--__-- Message: 1 Reply-To: <[email protected]> From: "Bernhard Woehrlin" <[email protected]> To: <[email protected]>, <[email protected]> Subject: AW: [Strutscx-user] My first contact with StrutsCX Date: Mon, 19 Jan 2004 14:56:17 +0100 Organization: IT.CappuccinoNet.com Hi Bertrand, Thanks for your comments on StrutsCX. Very helpful! Here some quick annotations: The checkBeanContent(Object bean) method of the StrutsCXBeanToElement originally build on an JavaWorld article by Julien Mercay and Gilbert Bouzeid 'Boost Struts with XSLT and XML'. So actually there was no need to look for another way to serialize Objects into XML. Of course the use of Castor XML is one option. - BTW, what advantages do you see in replacing the actual checkBeanContent with a Castor XML solution? One disadvantage I see, is the 1.1 MB size of Castor XML JAR. I followed your suggestion and added the ss.setSystemId(url.toString()); line to the createXSLTemplate() method of the StrutsCXStandardTransformer.=20 I haven't found time to check out and test your replacement of the StrutsCXURIResolver. To everybody: Comments on this appreciated... Greetings, Berny -----Urspr=FCngliche Nachricht----- Von: [email protected] [mailto:[email protected]] Im Auftrag von Bertrand Martel Gesendet: Sonntag, 18. Januar 2004 15:25 An: [email protected] Betreff: [Strutscx-user] 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) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 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 =3D javax.xml.parsers.DocumentBuilderFactory.newInstance().newDocumentBuilde r(). newDocument(); org.exolab.castor.xml.Marshaller.marshal(bean, dom); =09 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) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D =3D=3D=3D 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 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 =3D new StreamSource(urlConn.getInputStream()); ss.setSystemId(url.toString()); // <=3D=3D=3D=3D=3D=3D this is the = "magic" line to add xslTemplate =3D tFactory.newTemplates(ss); [...] b) <xsl:include href=3D"toto.xsl" /> & <xsl:import href=3D"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 =3D LogFactory.getLog(this.getClass()); =09 /** * 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 =3D documentRoot; } /** * This is called automatically from the Transformer.=20 * * @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 =3D null; try { URI hrefURI =3D new URI(href); url =3D this.documentRoot.resolve(hrefURI).toURL(); if (url =3D=3D null) { throw new TransformerException("Could not resolve resource " + href); } else { URLConnection urlConn =3D 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 _______________________________________________ Strutscx-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/strutscx-user --__--__-- _______________________________________________ Strutscx-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/strutscx-user End of Strutscx-user Digest ------------------------------------------------------- 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