Hi James,
please see inline.
Werner
James Cowan wrote:
Hi Werner
The GWT compiler takes java and compiles it into javascript;
unfortunately it will not compile any java that import e.g.
java.io.PrintWriter.
Here is a posting in the google developer forum from someone who has the
same problem (sorry about the long url):
http://groups.google.com/group/Google-Web-Toolkit/browse_thread/thread/60b5e608f0d28313/e838a0c1e9b23ccd?lnk=gst&q=castor#e838a0c1e9b23ccd
I just want to use the POJOs generated by XSD compiler in a GWT
environment (i.e. compiled with GWT compiler). I can make this happen by
switching off marshalling and descriptor generation and modifying the
sources using an ant script (see below). It is a bit ugly but it works.
Thanks for taking the time to explain this in further detail, and I now
do have a full appreciation of your problem.
This leads to the problem that if I want to use XML marshalling on the
server side, I then have to separate classes for client side and server
side which is a pain.
Hmm, using a fully-fledged build tool (both Ant and Maven come to my
mind), it should be possible (and quite easy) to always generate classes
on the fly (at build), but generate them twice - once for gwt, once for
your server processes. Yes, it would be double generation, but at least
that way your client/server classes would be in sync, given that the XML
schema is your starting point.
James
<antcall target="castor_compile">
<param name="p_xsd_file" value="${l_xsd}"/>
<param name="p_package" value="${l_castor_client_package}"/>
<param name="p_src_dir" value="${gl_src_dir}/${l_castor_client_dir}"/>
<param name="p_dest_dir" value="${gl_src_dir}"/>
<param name="p_nodesc" value="-nodesc"/>
<param name="p_nomarshall" value="-nomarshall"/>
</antcall>
<replace dir="${gl_src_dir}/${l_castor_client_dir}">
<include name="**/*.java"/>
<replacetoken><![CDATA[import java.io.Reader;]]></replacetoken>
</replace>
<replace dir="${gl_src_dir}/${l_castor_client_dir}">
<include name="**/*.java"/>
<replacetoken><![CDATA[import java.io.Writer;]]></replacetoken>
</replace>
<replace dir="${gl_src_dir}/${l_castor_client_dir}">
<include name="**/*.java"/>
<replacetoken><![CDATA[import java.util.Enumeration;]]></replacetoken>
</replace>
<replace dir="${gl_src_dir}/${l_castor_client_dir}">
<include name="**/*.java"/>
<replacetoken><![CDATA[java.util.Enumeration]]></replacetoken>
<replacevalue>void</replacevalue>
</replace>
<replace dir="${gl_src_dir}/${l_castor_client_dir}">
<include name="**/*.java"/>
<replacetoken><![CDATA[return new
org.exolab.castor.util.]]></replacetoken>
<replacevalue>//</replacevalue>
</replace>
</target>
----- Original Message ----- From: "Werner Guttmann"
<[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Sunday, November 04, 2007 5:12 PM
Subject: Re: [castor-user] castor and gwt
James,
excuse my stupidity, but how can import statements that refer to
classes in the java.io package produce any troubles ? Looks like you
need to re-iterate your problem.
Werner
James Cowan wrote:
Hi Werner
sorry it has taken ages for me to get back on this.
It is not possible to get the gwt compiler to compile the castor classes
because they include e.g.:
[java] [ERROR] Line 77: The import java.io.Reader cannot be
resolved
[java] [ERROR] Line 78: The import java.io.PrintWriter
cannot be
resolved
[java] [ERROR] Line 79: The import java.io.File cannot be
resolved
[java] [ERROR] Line 80: The import java.io.FileReader
cannot be
resolved
[java] [ERROR] Line 82: The import java.io.FileInputStream
cannot be resolved
[java] [ERROR] Line 83: The import java.io.InputStream
cannot be
resolved
[java] [ERROR] Line 84: The import java.io.IOException
cannot be
resolved
[java] [ERROR] Line 87: The import java.util.Enumeration
cannot
be resolved
[java] [ERROR] Line 88: The import java.util.Hashtable
cannot be
resolved
[java] [ERROR] Line 89: The import java.util.Properties
cannot
be resolved
[java] [ERROR] Line 90: The import java.util.StringTokenizer
cannot be resolved
[java] [ERROR] Line 91: The import java.util.Hashtable
cannot be
resolved
[java] [ERROR] Line 92: The import java.net cannot be
resolved
gwt is highly restrictive in what it can compile.
The only way to get round is to put the marshalling code into separate
class/package.
James
----- Original Message ----- From: "Werner Guttmann"
<[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Monday, October 15, 2007 3:40 PM
Subject: Re: [castor-user] castor and gwt
James,
James Cowan wrote:
Hi
I have been using castor successfully with gwt to generate the domain
objects passed using gwt-rpc.
I have had to make a few hacks to munge the generated beans (fixed I
believe in the latest source generator).
The main remaining problem is that I have to switch off marshalling
otherwise the gwt javascript compiler complains.
Mind explaining to us the reason for this ? I'd like to underrstand
that a
bit more in detail before thinking about any possible resolutions.
This is a bit of a pity because I would like to populate objects
from xml
files. I have come up with one hack whereby I generate one version
of the
xsd without marshalling for use with gwt and another version which
contains the marshalling code so that I can read xml file; I then
use a
bean copy utility to copy from one bean to another. This is a bit
clunky.
Any other ways that i could get round this?
One nice solution would be if the marshalling code could be in a
separate
class/package which I could then instruct the gwt javascript
compiler to
ignore. Would that be feasible?
Not sure, but possible.
But let's first talk about the problem.
James
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
