gzilla/show_bug.cgi?id=19138
[Contrib]/[Patch] Made SQLTransformer paginatable.
--- Additional Comments From [EMAIL PROTECTED] 2003-06-11 15:42 ---
Created an attachment (id=6764)
joerg's patch for bug#14977 modified SQLTransformer a bit.
gzilla/show_bug.cgi?id=20631
[PATCH] Support for transactions in SQLTransformer
--- Additional Comments From [EMAIL PROTECTED] 2003-06-10 03:15 ---
Created an attachment (id=6729)
modified SQLTransformer (in full)
gzilla/show_bug.cgi?id=20631
[PATCH] Support for transactions in SQLTransformer
Summary: [PATCH] Support for transactions in SQLTransformer
Product: Cocoon 2
Version: 2.0.4
Platform: All
OS/Version: All
Status: NEW
Severity:
gzilla/show_bug.cgi?id=14977
SQLTransformer serializeData method
--- Additional Comments From [EMAIL PROTECTED] 2003-05-29 21:52 ---
Created an attachment (id=6556)
the NPE patch as diff file
gzilla/show_bug.cgi?id=14977
SQLTransformer serializeData method
--- Additional Comments From [EMAIL PROTECTED] 2003-05-29 21:51 ---
The patch sounds very reasonable and logical, but why does this NPE not occur
more often, i.e. why do not more people stumble over the NPE?
SQLTransformer and so on... But this is off-topic here.
Realizing that SQLTransformer is an evolutionary dead end, I guess I will
revisit my original problem. There go a few more days :-(
My first choice was ESQL. And I also noticed SQLTransformer is absent
from
Cocoon 2.1.
huh?
http
Hi!
Torsten Curdt wrote:
Hi!
The SQLTransformer lacks an important feature that is present in
the ESQL logicsheet. ESQL allows limiting the number of rows
returned from a database using and skips
some rows using the tag.
I have implemented something similar for the SQLTransformer. The
patch
Hi!
The SQLTransformer lacks an important feature that is present in
the ESQL logicsheet. ESQL allows limiting the number of rows
returned from a database using and skips
some rows using the tag.
I have implemented something similar for the SQLTransformer. The
patch is very simple and I think
Hi!
This is my first attempt at submitting a pathc/proposal for Cocoon.
I hope I don't press the wrong buttons.
The SQLTransformer lacks an important feature that is present in
the ESQL logicsheet. ESQL allows limiting the number of rows
returned from a database using and skips
some rows
ocoon 2.0.4 SQLTransformer produces a blank page for output on the
above
query structure. I researched the problem enough to realize that the
SQLTransformer
does not even execute the queries because the current_query_index variable
never
gets back down to zero (which is the trigger for callin
gzilla/show_bug.cgi?id=17984
SQLTransformer only handles nested or sequential queries
Summary: SQLTransformer only handles nested or sequential queries
Product: Cocoon 2
Version: 2.0.4
Platform: PC
OS/Version: Windows NT/2K
Statu
gzilla/show_bug.cgi?id=13344
SQLTransformer: syntax error when submitting Oracle Stored Procedures spanning more
than one line of code
[EMAIL PROTECTED] changed:
What|Removed
gzilla/show_bug.cgi?id=13344
SQLTransformer: syntax error when submitting Oracle Stored Procedures spanning more
than one line of code
[EMAIL PROTECTED] changed:
What|Removed
gzilla/show_bug.cgi?id=12173
[PATCH] SQLTransformer Query object prematurely closes connection causing
NullPointerException when accessing ResultSet
--- Additional Comments From [EMAIL PROTECTED] 2003-03-02 17:31 ---
Created an attachment (id=5101)
Test scenario that may be related, to
Dear All,
I have made XSD and CSS for the SQLTransformer tagset to be edited by
XMLMind XMLEditor (XXE) for my own project.
The XSD is designed to be imported into your own Document XSD to work
around the 'limited namespace' issue in the free version of XXE.
Several people expresse
gzilla/show_bug.cgi?id=16718
[PATCH] Using only one connection in SQLTransformer
--- Additional Comments From [EMAIL PROTECTED] 2003-02-03 16:14 ---
Created an attachment (id=4694)
Patch for the SQLTransformer
-
To unsubscr
gzilla/show_bug.cgi?id=16718
[PATCH] Using only one connection in SQLTransformer
Summary: [PATCH] Using only one connection in SQLTransformer
Product: Cocoon 2
Version: 2.0.4
Platform: All
OS/Version: All
Status: NEW
Severity: Enhan
gzilla/show_bug.cgi?id=12173
[PATCH] SQLTransformer Query object prematurely closes connection causing
NullPointerException when accessing ResultSet
[EMAIL PROTECTED] changed:
What|Removed
gzilla/show_bug.cgi?id=12173
SQLTransformer Query object prematurely closes connection causing NullPointerException
when accessing ResultSet
--- Additional Comments From [EMAIL PROTECTED] 2003-01-09 18:31 ---
I now even suspect that this patch fixes the NPEs that used to affect 2.0.3
an
gzilla/show_bug.cgi?id=12173
SQLTransformer Query object prematurely closes connection causing NullPointerException
when accessing ResultSet
[EMAIL PROTECTED] changed:
What|Removed
gzilla/show_bug.cgi?id=12173
SQLTransformer Query object prematurely closes connection causing NullPointerException
when accessing ResultSet
--- Additional Comments From [EMAIL PROTECTED] 2003-01-09 18:23 ---
Created an attachment (id=4386)
removes the premature conn.close() in Query.e
The problem therefore is with the SQLTransformer.Query inner class which
closes the Connection at the end of execute(), but the SQLTransformer still
tries to access the resultset to read the rows.
This does not work with DBCP because the ResultSet.close() is called when
Connection.close() is c
Hi,
Using SQLTransformer, can someone advise how to insert xml or an xml
fragment into a database column?
For example, I try
...
insert into test_table ( xml_frag ) values ( 'of
xml' )
And all that gets inserted into the xml_frag field is 'of xml'. It looks
like
onvinced a rewriting of SQLTransformer is needed to handle transactions... I tried the following:
name="test">
begin
DELETE FROM CRRegion
WHERE Id > 80;
COMMIT;
INSERT INTO CRRegion
(Id, Name)
VALUES
('90', 'Foo');
INSERT INTO CRRegion
(Id
Sylvain Wallez wrote:
I consider that getting a connection from the pool for each
creates some unnececessary load on the pool. So I would
go for the first solution (use the same connection).
I will try that.
There will still be a need for new connections for sub queries, to reuse
the same co
> -Original Message-
> From: Sylvain Wallez [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, December 15, 2002 1:48 PM
> To: [EMAIL PROTECTED]
> Subject: Re: SQLTransformer and Transactions
> In the above example, the transaction is contained in a _single_
> element. Wh
Luca Morandini wrote:
Sylvian,
I'm not completely convinced a rewriting of SQLTransformer is needed to handle transactions... I tried the following:
name="test">
begin
DELETE FROM CRRegion
WHERE Id > 80;
COMMIT;
INSERT INTO CRRegion
(Id, Name)
Antonio Gallardo wrote:
Can you explain what you have in mind Sylvain? I dont understand what you
have in mind.
I guess it's the "load on the pool" that is unclear.
What I'm saying is that I consider a waste of CPU to get a connection
from the same pool for each encountered in the
document
Sylvian,
I'm not completely convinced a rewriting of SQLTransformer is needed to handle
transactions... I tried the following:
name="test">
begin
DELETE FROM CRRegion
WHERE Id > 80;
COMMIT;
Can you explain what you have in mind Sylvain? I dont understand what you
have in mind.
Antonio Gallardo
Sylvain Wallez dijo:
>
> I consider that getting a connection from the pool for each
> creates some unnececessary load on the pool. So I would
> go for the first solution (use the same conne
Daniel Fagerstrom wrote:
I'd like to use transactions in the SQLTransformer and tried something
like:
...
BEGIN;
Do something
Do something that is based on the previous query
COMMIT;
...
This does not work in the current implementation o
I'd like to use transactions in the SQLTransformer and tried something like:
...
BEGIN;
Do something
Do something that is based on the previous query
COMMIT;
...
This does not work in the current implementation of the SQLTransformer
as it g
-
> -Original Message-
> From: Rano, Didier [mailto:[EMAIL PROTECTED]]
> Sent: Friday, December 06, 2002 10:09 PM
> To: [EMAIL PROTECTED]
> Subject: SQLTransformer
>
>
>
>
> I am using Cocoon 2.0.3 with Oracle 8i and driver for java 1.2 (classes12.zip)
>
> I
I am using Cocoon 2.0.3 with Oracle 8i and driver for java 1.2 (classes12.zip)
I have a problem with values get of a simple request (
select myString from myTable). In fact, in the class SQLTransformer, method
getColumnValue( int), the function getObject returns null, and at this moment
Carsten Ziegeler [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, December 04, 2002 10:20 AM
> To: [EMAIL PROTECTED]
> Subject: RE: Bug 13344 (SQLTransformer) still open
>
>
>
>
> > -Original Message-
> > From: Luca Morandini [mailto:[EMAIL PROTECTED]]
> > Se
> -Original Message-
> From: Luca Morandini [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, December 04, 2002 9:49 AM
> To: Cocoon-dev
> Subject: Bug 13344 (SQLTransformer) still open
>
>
>
> while I won't describe this as a showstopper, I deem usefu
while I won't describe this as a showstopper, I deem useful solving it before the
2.0.4 release,
Carsten, I know the solution I provided seems to cure only the effect and not the
cause... but, have you a better solution ?
Best regards,
-
gzilla/show_bug.cgi?id=14977
SQLTransformer serializeData method
Summary: SQLTransformer serializeData method
Product: Cocoon 2
Version: Current CVS
Platform: PC
OS/Version: All
Status: NEW
Severity: Major
Priority:
Carsten Ziegeler wrote:
Hi Team,
I'm really getting more and more amazed by our latest repository
(HEAD). We not only have jars without versioning information,
Totally agree with you, +1 for fixing it.
but there are also some things missing.
Where is the SQLTransformer?
Ar
Carsten Ziegeler wrote:
> Hi Team,
>
> I'm really getting more and more amazed by our latest repository
> (HEAD). We not only have jars without versioning information,
> but there are also some things missing.
>
> Where is the SQLTransformer?
>
> I can't
gzilla/show_bug.cgi?id=14466
SQLTransformer doubles namespace declarations in output
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|RESOLVED|
gzilla/show_bug.cgi?id=14466
SQLTransformer doubles namespace declarations in output
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |RE
Hi Team,
I'm really getting more and more amazed by our latest repository
(HEAD). We not only have jars without versioning information,
but there are also some things missing.
Where is the SQLTransformer?
I can't recall any vote on removing this - or did I simply oversee
it. Pleas
gzilla/show_bug.cgi?id=14466
SQLTransformer doubles namespace declarations in output
Summary: SQLTransformer doubles namespace declarations in output
Product: Cocoon 2
Version: 2.0.3
Platform: Sun
OS/Version: Solaris
Status: NEW
Se
gzilla/show_bug.cgi?id=14314
Support for JDBC Array in SQLTransformer
Summary: Support for JDBC Array in SQLTransformer
Product: Cocoon 2
Version: Current CVS
Platform: All
OS/Version: All
Status: NEW
Severity: Enhan
gzilla/show_bug.cgi?id=13344
SQLTransformer: syntax error when submitting Oracle Stored Procedures spanning more
than one line of code
Summary: SQLTransformer: syntax error when submitting Oracle
Stored Procedures spanning more than one line of code
Product: Co
Fill it up into bugzilla. This way it should not get forgotten.
Giacomo
On Sun, 6 Oct 2002, Luca Morandini wrote:
> Folks,
>
> on the 1st of Oct, I've sent this list a code fragment to address an error in the
>SQLTransformer shipped with the 2.0.3.
>
> I'd like t
Folks,
on the 1st of Oct, I've sent this list a code fragment to address an error in the
SQLTransformer shipped with the 2.0.3.
I'd like to know whether anyone of you will commit that patch to the code base,
possibily for the up-coming 2.0.4 or the 2.1.
Be
gzilla/show_bug.cgi?id=12173
SQLTransformer Query object prematurely closes connection causing NullPointerException
when accessing ResultSet
Summary: SQLTransformer Query object prematurely closes
connection causing NullPointerException when acc
> second:
> I don't want to rain on your parade, but...
> from an architectural point of view: is
> "resolver.resolve("cocoon://dynamic-sql")" in XSP so much
> better than "document()" in XSLT ?
>
> Yes, the first is cached, and I agree (up to a point, though)
> that SQL queries belong to gene
nd(sb);
you could just use:
String sb = XSPUtil.getContents(source);
--Steve
> -Original Message-
> From: Vadim Gritsenko [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, July 13, 2002 10:27 AM
> To: [EMAIL PROTECTED]
> Subject: RE: [PROPOSAL] Remove SQLTransformer i
>
>
>Yepp!
>
>Andrew, give me a mail when you are ready to start...
>...maybe we can work this out together...
>
Cool . Will do. It is currently on the queue in position #9. I will
inform you if it moves to position #1 or if
it moves down too many positions.
Thanks,
Andy
>--
>Torsten
>
>---
On Saturday 13 July 2002 21:32, Vadim Gritsenko wrote:
> > From: Andrew C. Oliver [mailto:[EMAIL PROTECTED]]
> >
> > Vadim,
> >
> > My parade was to do achieve the following:
> >
> > 1. Excite a final decision on whether the SQLTransformer is deprecated
> From: Andrew C. Oliver [mailto:[EMAIL PROTECTED]]
>
> Vadim,
>
> My parade was to do achieve the following:
>
> 1. Excite a final decision on whether the SQLTransformer is deprecated
> or not
> 2. Excite an effort (if not) to clean both SQLTransformer and ESQL
Vadim,
My parade was to do achieve the following:
1. Excite a final decision on whether the SQLTransformer is deprecated
or not
2. Excite an effort (if not) to clean both SQLTransformer and ESQL if
not (SQLTransformer is *slow*)
It sounds like the answer is there is a need still for
> From: Luca Morandini [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, July 13, 2002 1:29 PM
> To: [EMAIL PROTECTED]
> Subject: RE: [PROPOSAL] Remove SQLTransformer in 2.1
>
>
> Vadim & Andrew,
>
> first:
> thanks.
>
> second:
> I don't want to
ter... I should try
this.
Best regards,
P.S.
A personal note, I use SQLTransformer not because "ESQL is more hidden in the
documentation" but because it supported stored
procedures long before EQSL.
-
Luca Morandini
> From: Andrew C. Oliver [mailto:[EMAIL PROTECTED]]
>
> Vadim Gritsenko wrote:
>
> >>From: Luca Morandini [mailto:[EMAIL PROTECTED]]
> >>
> >>Andrew,
> >>
> >>do you mind terribly showing an example of an ESQL feeded by
> >>a dynamic query produced by XSLT ?
> >
> >I don't mind. Moreover, somet
Vadim Gritsenko wrote:
>>From: Luca Morandini [mailto:[EMAIL PROTECTED]]
>>
>>Andrew,
>>
>>do you mind terribly showing an example of an ESQL feeded by a dynamic
>>
>>
>query
>
>
>>produced by XSLT ?
>>
>>
>
>I don't mind. Moreover, something tells me I already answered similar
>questio
> From: Luca Morandini [mailto:[EMAIL PROTECTED]]
>
> Andrew,
>
> do you mind terribly showing an example of an ESQL feeded by a dynamic
query
> produced by XSLT ?
I don't mind. Moreover, something tells me I already answered similar
question on user list...
Will it help you if I answer?
Vadi
>http://utenti.tripod.it/lmorandini/index.html
>-
>
>
>
>
>>-Original Message-
>>From: Andrew C. Oliver [mailto:[EMAIL PROTECTED]]
>>Sent: Saturday, July 13, 2002 3:17 PM
>>To: [EMAIL PRO
/lmorandini/index.html
-
> -Original Message-
> From: Andrew C. Oliver [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, July 13, 2002 3:17 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [PROPOSAL] Remove SQLTransformer in 2.1
>
>
Torsten Curdt wrote:
>>P.S.
>>I use SQLTransformer only, and I'm happy with it :) don't deprecate it :(
>>
>>
>
>I guess it would be cool for both ESQL and the SQLTransformer to share code as
>well as syntax. But this will probably break backwards
> P.S.
> I use SQLTransformer only, and I'm happy with it :) don't deprecate it :(
I guess it would be cool for both ESQL and the SQLTransformer to share code as
well as syntax. But this will probably break backwards compatibility for
both. IMHO it could be nice to start a n
Andrew,
may you give me an example on how to process the output of an XSLT transformation
using ESQL ?
Thank in advance,
P.S.
I use SQLTransformer only, and I'm happy with it :) don't deprecate it :(
-
Luca
Per Kreipke wrote:
>>>Personally I much prefer esql to SQLTransformer because I can control
>>>the caching in an xsp.
>>>
>>>Anyway it isn't quite true that you can't do "transformation" in an xsp:
>>>I have SQL which is dynamicall
Yuppo. To me a big problem is that the SQLTransformer performs poorly,
users start off using it
because ESQL is more hidden in the documentation for instance, and then
"Gee cocoon is slow"...
-Andy
Stephen Ng wrote:
>This is true, but the coding is trivial--it's just one l
to a use-case I suppose).
Steve
> -Original Message-
> From: Per Kreipke [mailto:[EMAIL PROTECTED]]
> Sent: Friday, July 12, 2002 11:54 AM
> To: [EMAIL PROTECTED]
> Subject: RE: [PROPOSAL] Remove SQLTransformer in 2.1
>
>
> > >Personally I much prefer esql
> >Personally I much prefer esql to SQLTransformer because I can control
> >the caching in an xsp.
> >
> >Anyway it isn't quite true that you can't do "transformation" in an xsp:
> >I have SQL which is dynamically generated from an xslt transfo
refactoring sounds like a good idea as long as the SQLTransformer
>is not dependend on any XSP stuff.
>
>
I would consider that a given. Great then.
>Carsten
>
>-
>To unsubscribe, e-m
Stephen Ng wrote:
>Personally I much prefer esql to SQLTransformer because I can control
>the caching in an xsp.
>
>Anyway it isn't quite true that you can't do "transformation" in an xsp:
>I have SQL which is dynamically generated from an xslt transformer whic
>> Andrew C. Oliver wrote:
>>
>>
>>> Hi All,
>>>
>>> Backward compatibility among minor revisions is generally a smart
>>> and good thing to do. However, there does
>>> become a point where it grows six legs and starts biting you.
Andrew C. Oliver wrote:
> >-10
> >
> >The SQLTransformer provides a very good alternative to ESQL, it is in
> >some use cases more flexible as it is a transformer and not a generator.
> >And you don't need XSP to use it.
> >
> >The SQLTransformer
among minor revisions is generally a smart and
>>good thing to do. However, there does
>>become a point where it grows six legs and starts biting you.
>>
>>The ESQL generator AFAIK supports everything one could need to do via
>>the SQLTransformer and there does not s
>
>
>>
>>
>-10
>
>The SQLTransformer provides a very good alternative to ESQL, it is in
>some use cases more flexible as it is a transformer and not a generator.
>And you don't need XSP to use it.
>
>The SQLTransformer in its current state is
a use case though. The only ones I can think of don't make much sense
or are outstandingly bad practice or
could be accomplished other ways anyhow. Any thoughts?
-Andy
>
>
>>:)
>>
>>
>>PS SQLTransformer code might be messy. But functionality it
>>pro
Personally I much prefer esql to SQLTransformer because I can control
the caching in an xsp.
Anyway it isn't quite true that you can't do "transformation" in an xsp:
I have SQL which is dynamically generated from an xslt transformer which
I then feed into my esql. I use the
>
>
>Here is one...
>
>xml-cocoon2\src\scratchpad\src\org\apache\cocoon\taglib\Tag.java
>
>If this idea picks up, SQLTransformer will be re-implemented as a set of
>tags (one tag?), and ESQL will be deprecated.
>
>:)
>
>
>PS SQLTransformer code might be
one could need to do via
> the SQLTransformer and there does not seem
> to be a reason to continue to support both technologies.
>
> IMHO, while the code quality of the ESQL stylesheet is relatively low,
> the quality of the SQLTransformer is lower probably due to code rot and
> neg
> From: Vadim Gritsenko [mailto:[EMAIL PROTECTED]]
> > From: Andrew C. Oliver [mailto:[EMAIL PROTECTED]]
> > Bertrand Delacretaz wrote:
> > >On Thursday 11 July 2002 22:44, Andrew C. Oliver wrote:
> > >
> > >>. . .
> > >>I'd like
> From: Andrew C. Oliver [mailto:[EMAIL PROTECTED]]
>
> Bertrand Delacretaz wrote:
>
> >On Thursday 11 July 2002 22:44, Andrew C. Oliver wrote:
> >
> >>. . .
> >>I'd like to propose we remove the SQLTransformer from Cocoon 2.1 and
> >>new
>
>
>How can that be true? The transformation point in the pipeline is very
>different than a generator. For example, I can order transformations such
>that the SQL transformer comes between other transforms but you couldn't do
>that with a generator.
>
>
Very few times is there a reason to buil
>
> ESQL is certainly more developed, but it is not a replacement. Where
> in SQLTransformer do you suspect code rot? Have people been
> experiencing problems with it?
Open up the sourceode for the transformer, look at the amount of
repetitive code.. . The SQL Transformer
Per Kreipke wrote:
The ESQL generator AFAIK supports everything one could need to do via
the SQLTransformer and there does not seem
to be a reason to continue to support both technologies.
How can that be true? The transformation point in the pipeline is very
different than
> The ESQL generator AFAIK supports everything one could need to do via
> the SQLTransformer and there does not seem
> to be a reason to continue to support both technologies.
How can that be true? The transformation point in the pipeline is very
different than a generator. For examp
Bertrand Delacretaz wrote:
>On Thursday 11 July 2002 22:44, Andrew C. Oliver wrote:
>
>
>>. . .
>>I'd like to propose we remove the SQLTransformer from Cocoon 2.1 and
>>newer releases, remove all SQLTransformer based samples (or provide esql
>>alterna
On Thursday 11 July 2002 22:44, Andrew C. Oliver wrote:
>. . .
> I'd like to propose we remove the SQLTransformer from Cocoon 2.1 and
> newer releases, remove all SQLTransformer based samples (or provide esql
> alternatives).
(I have no formal voting rights here but)
-1
Why r
Hi All,
Backward compatibility among minor revisions is generally a smart and
good thing to do. However, there does
become a point where it grows six legs and starts biting you.
The ESQL generator AFAIK supports everything one could need to do via
the SQLTransformer and there does not seem
gzilla/show_bug.cgi?id=9105
[PATCH] Fixed Bug in SQLTransformer when doing INSERT or UPDATE
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|RESOLVED|
gzilla/show_bug.cgi?id=9105
[PATCH] Fixed Bug in SQLTransformer when doing INSERT or UPDATE
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |RE
gzilla/show_bug.cgi?id=9105
[PATCH] Fixed Bug in SQLTransformer when doing INSERT or UPDATE
--- Additional Comments From [EMAIL PROTECTED] 2002-05-15 08:44
---
Created an attachment (id=1863)
Patch to SQLTransformer
--
gzilla/show_bug.cgi?id=9105
[PATCH] Fixed Bug in SQLTransformer when doing INSERT or UPDATE
Summary: [PATCH] Fixed Bug in SQLTransformer when doing INSERT or
UPDATE
Product: Cocoon 2
Version: 2.0.2
Platform: Other
OS/Version:
Hi!
> I guess it would be perfect, for example, to get some
> addresses from database in SQLTransformer and send email
> to addresses returned, this gives simple way to build
> maillists, for example.
Hmm, just figured out that this can be done by using
aggregator with ESQL
Hi!
> P.S. Anyone interested in a simple EmailTransformer -
> i.e. a transformer that interprets email descriptions
> and sends emails, but leaves the rest of the document
> intact?
Count me.
I guess it would be perfect, for example, to get some
addresses from database in SQ
, Nicola Ken Barozzi wrote:
> - Original Message -
> From: "Luca Morandini" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Monday, January 21, 2002 9:48 AM
> Subject: RE: esql Vs SQLTransformer
>
>
> > Valentin,
> >
> &
- Original Message -
From: "Luca Morandini" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, January 21, 2002 9:48 AM
Subject: RE: esql Vs SQLTransformer
> Valentin,
>
> I don't think SQL Transformer is deprecated, since it was patched in
.jar and
avalon-framework-20011126.jar.
With avalon-excalibur-20011126.jar and avalon-framework-20011126.jar
I get a java.lang.IllegalMonitorStateException when using the
SQLTransformer.
The log from components.log is attached to the mail.
Peter Seiderer
I am not subscribed to the mailing list
ect: PATCH: add advanced error handling in SQLTransformer plus
> escape-string element
>
>
> Hello,
> the patch attached above brings the following two changes to the
> SQLTransformer:
>
> 1. SQLExceptions coming from query.execute() are catched and the following
> output
Hello,
the patch attached above brings the following two changes to the
SQLTransformer:
1. SQLExceptions coming from query.execute() are catched and the following
output is added to the resulting xml documenters set
The error messge from the SQLException.
2. The element is added. The
i is correct, though
Looking into the code of the SQLTransformer one detects that
there is no implementation of the start- and endPrefixMapping.
To my knowledge, there is no way of knowing the prefix to output
if the start- and endPrefixMapping methods aren´t implemented?
Is there a design reas
1 - 100 of 135 matches
Mail list logo
