Hi,
thanks for your work. Comments follow interspersed, but first one word
to the utf8 problem. A quick hack in interclient, setting the default
character set to utf8 in ConnectionProperties.java and DataSource.java
solves the problem, no exception any longer with non US ASCII characters
(e.g.: üöä). I know that is no software engineering and no common
solution but it shows that the character set of the connection is not
set correctly. When we take a second look in the server.log:
[InterBaseDB] Starting
[InterBaseDB] No transaction right now.
[InterBaseDB] XA Connection pool InterBaseDB bound to java:/InterBaseDB
[InterBaseDB] org.jboss.minerva.xa.XADataSourceImpl created new
Connection
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
(interbase.interclient.Connection) with XAResource
org.jboss.minerva.xa.XAResourceImpl and XAConnection
org.jboss.minerva.xa.XAConnectionImpl.
[InterBaseDB] Pool InterBaseDB [0/0/Unlimited] gave out new object:
org.jboss.minerva.xa.XAConnectionImpl@2d3b783a
[InterBaseDB] Pool InterBaseDB [0/1/Unlimited] returned object
org.jboss.minerva.xa.XAConnectionImpl@2d3b783a to the pool.
[InterBaseDB] Started
We see that no DataSource Object from Interclient is created, it is an
object from org.jboss.minerva.xa.XADataSourceImpl created which
constructs the connection. Therefor the charSet argument don't work with
the Datasource class. Perhaps the jboss-DataSource class have to be
exchanged with that one from interclient. But I don't know how and if
this is a solution.
David Jencks wrote:
>
> Hi,
>
> Thanks for testing this out.
>
> Comments interspersed below, but mostly UTF8 works ok for my regression
> tests (standalone). The CD store looks familiar but I can't remember where
> it comes from. Any hints? Maybe I could work some more if I had the
> example.
You find it at the jboss home-page->Documentation-> Advanced Topics:
Using container-managed persistence with jboss-> Step 2 -> Link: 'Click
here' above horizontal line
> Looking at the exception again... I see an accented character in cafe. Can
> you change it to unaccented e and see if it fails?
All US ASCII char work all non US ASCII chars not, german 'Umlaute'
including: üöäÜÖÄß
> I just copied and pasted 'Café' into an insert statement run through ant
> and ant said, roughly, Character conversion error-malformed utf-8
> character.... (before it got to thinking about talking to interclient)
>
> This makes me wonder if the 'é' is supplied to interclient in a valid UTF8
> encoding. Do you know of any comprehensible and non boat anchor sized
> unicode information?
You find a lot of unicode info at www.unicode.org. I think the
characters are converted correctly but the interbase connection is not
switched to unicode, see above comments. Against my information all java
strings are unicode strings therefor the 'é' letter should unicode
encoded too.
For tests use the CD example and create a simple java client with direct
interbase connection and set the charSet of the datasoure. That should
work.
> Thanks
>
> David Jencks
> On 2001.02.27 03:03:26 -0500 Dirk Ohst wrote:
> > Hi,
...
> > With ant I'got the following error:
> >
> > ------------------------
> > dev/firebird> ant
> > Searching for build.xml ...
> > Buildfile: /home/ohst/interclient/20/dev/firebird/build.xml
> >
> > setup.java:
> >
> > BUILD FAILED
> >
> > /home/ohst/interclient/20/dev/firebird/build.xml:21: Directory
> > /home/build/interclient/dev/classes creation was not succesful for an
> > unknown reason
> >
> > Total time: 1 second
> > ------------------------
>
> I am assuming you have directory structure like
> ..../firebird/CVS/interclient/20/dev/firebird/build.xml
>
> Your build failed because ant couldn't make a /home/build directory. I'd
> like to keep any compiled files out of the CVS tree.
The interclient directory from CVS tree is in my home:
~/interclient/20/...
OK, just adjusted the path variables (I am also new to ant :-) and I got
an other error:
-----------------
dev/firebird> ant
Searching for build.xml ...
Buildfile: /home/ohst/interclient/20/dev/firebird/build.xml
setup.java:
compile.java:
[javac] Compiling 106 source files to
/home/ohst/build/interclient/dev/class
es
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -deprecation for details.
jar:
[jar] Building jar: /home/ohst/build/interclient/interclient.jar
dist.jar:
[copy] Copying 1 files to /home/ohst
setup.cpp:
[mkdir] Created dir: /home/ohst/build/interclient/dev/interserver
[mkdir] Created dir: /home/ohst/build/interclient/dev/bin
[mkdir] Created dir: /home/ohst/bin
compile.cpp:
BUILD FAILED
/home/ohst/interclient/20/dev/firebird/build.xml:48: Could not create
task of ty
pe: transform because I can't find it in the list of task class
definitions. Co
mmon solutions are: 1 execute bin/bootstrap. 2 use taskdef to declare
your task.
3 add the task to defaults.properties.
Total time: 16 seconds
----------------------------
> >
> >
> > But it worked with make in the packages and interbase directory after
> > some small
> > corrections in XAResource.java, interbase/Makefile and event_msgs.h
> > because of a compile errors:
> >
> > in XAResource.java
> > used:
> > ------------------------
> > ...
> > synchronized public void setTransactionTimeout(int seconds) throws
> > javax.transaction.xa.XAException {
> > return ; //not yet supported
> > }
> > ...
> > ------------------------
> >
> >
> > instead of:
> > ------------------------
> > ...
> > synchronized public boolean setTransactionTimeout(int seconds) throws
> > javax.transaction.xa.XAException {
> > return false; //not yet supported
> > }
> > ...
> > ------------------------
>
> What javax.transaction.xa.XAResource do you have? Mine indicates that this
> method should return a boolean. Doesn't matter much, this XA stuff is a
> red herring, its completely not implemented.
I don't know where I have found it, perhaps from SUN's J2EE. It should
not be a problem.
> >
> > in event_msgs.h problem with C macros spanning multple lines ?!? I don't
> > know why, have had up to now never such a problem.
>
> This is a mystery to me also
> >
> > renamed CDR.[ch] to cdr.[ch] in all files.
>
> Also a mystery to me, the file names I have are CDR.h etc not cdr.h.
Sorry, this could a copy from W2k to linux problem. Got the source with
WinCVS an testet on linux. At the Win side the file is uppercase.
Many thanks,
Dirk Ohst.
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
List Help?: [EMAIL PROTECTED]
