You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Donald Ball <ba...@webslingerZ.com> on 2001/06/19 21:02:25 UTC
bugs in the xsp logicsheet application process
hey guys, once again, nasty bugs in the xsp logicsheet application process
have come up to bite me. i've got a logicsheet of my own that calls the
xsp-request logicsheet:
<xsl:template match="wzi:page">
<w:page>
<xsp:logic>
int work_max_rows = 10;
int work_skip_rows = 0;
try {
work_max_rows = Integer.parseInt(<xsp-request:get-parameter
name="work-max-rows"/>);
} catch (Exception e) {}
try {
work_skip_rows = Integer.parseInt(<xsp-request:get-parameter
name="work-skip-rows"/>);
} catch (Exception e) {}
</xsp:logic>
<xsl:apply-templates/>
</w:page>
</xsl:template>
it gets turned into this malformed java code:
int work_max_rows = 10;
int work_skip_rows = 0;
try {
work_max_rows = Integer.parseInt(
xspAttr.addAttribute("", "name", "name", "CDATA", "work-max-rows");
this.contentHandler.startElement(
"http://apache.org/xsp/request","get-parameter",
"xsp-request:get-parameter",
xspAttr);
xspAttr.clear();
this.contentHandler.endElement(
"http://apache.org/xsp/request",
"get-parameter",
"xsp-request:get-parameter");
);
} catch (Exception e) {}
...
as you can see, the xsp-request logicsheet isn't being applied... but in
my cocoon.log file, i see the following:
DEBUG 25662 [cocoon ] (HttpProcessor[8080][4]): Making URL from
file:/usr/local/jakarta-tomcat-4.0-b5/webapps/intranet/content/clients.xml
DEBUG 25664 [cocoon ] (HttpProcessor[8080][4]): Making URL from
jndi:/localhost/intranet/WEB-INF/xsp/shared.xsp
DEBUG 25665 [cocoon ] (HttpProcessor[8080][4]): Logicsheet
Used:jndi:/localhost/intranet/WEB-INF/xsp/shared.xsp
DEBUG 25665 [cocoon ] (HttpProcessor[8080][4]): Adding embedded logic
sheet for
xsp-request:jar:jndi:/localhost/intranet/WEB-INF/lib/cocoon.jar!/org/apache/cocoon/components/language/markup/xsp/java/request.xsl
DEBUG 25665 [cocoon ] (HttpProcessor[8080][4]): Making URL from
jar:jndi:/localhost/intranet/WEB-INF/lib/cocoon.jar!/org/apache/cocoon/components/language/markup/xsp/java/request.xsl
DEBUG 25665 [cocoon ] (HttpProcessor[8080][4]): Logicsheet
Used:jar:jndi:/localhost/intranet/WEB-INF/lib/cocoon.jar!/org/apache/cocoon/components/language/markup/xsp/java/request.xsl
(shared.xsp is my logicsheet, operating on the wzi namespace prefix)
any idea what's up with this?
- donald
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
[C2] Talking 'bout sql connections ...
Posted by Jose de Zarate <jz...@spainmail.com>.
Hello.
Now that we're talking 'bout sql connections, I think there is something that
could be fixed in
the database actions (maybe):
There are some jdbc drivers that doesn't let use the "con.setAutocommit(true)"
method, and throws
an exception when this is called. More precisely, I'm talking about the jdbc
driver for MySQL (mm.mysql.jdbc).
Although you can set the Autocommit behavior on or off in the datasource section of
the cocoon.xconf file, the "databaseadd/remove/update"
actions make a call at this method. I've had to comment out those lines, and
everything works ok, but wouldn't it be better to make the action able to decide
whether yes or not to use the autocommit method by its own? (maybe through a
parameter in the descriptor file, or reading from the "datasource" section of the
cocoon.xconf file).
txs a lot
Bye!
José de Zárate
jzarate@spainmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: javax.sql.DataSource
Posted by Berin Loritsch <bl...@apache.org>.
> > > 2. esql.xsl. In case when a connection is obtained from DataSource one
> > > should not invoke setAutoCommit() method. Otherwise SQLException will be
> > > thrown. Looking at esql.xsl, I've found that you catch any exceptions thrown
> > > by this method but you rethrow RuntimeException which is incorrect. I don't
> > > think you should throw any exception in this exception handler. See esql.xsl
> > > line 362.
would it be propper of us to only setAutoCommit if we are manually declaring our
connection? I would think so--esp. since Avalon's DataSourceComponent manages
the AutoCommit correctly.
> I have not forgotten about Cocoon 1 version of esql.xsl. I am trying to get a
> fresh copy of it from CVS, but my client is chugging for a long time. Once I
> get it, I will commit the same change in Cocoon 1.
This part is done.
Re: javax.sql.DataSource
Posted by Berin Loritsch <bl...@apache.org>.
Berin Loritsch wrote:
>
> kesha wrote:
> >
> > Hi guys,
> >
> > I've tried to deploy cocoon into WL 6.0 server and use DataSource as a jdbc
> > Connection factory. Doing that, I've found a couple of bugs. Could anybody
> > to commit the following changes into CVS:
> >
> > 1. cocoon.roles, role name
> > "org.apache.avalon.excalibur.datasource.DataSourceComponentSelector". The
> > hint for j2ee points to the wrong class name. Insteed of
> > "org.apache.avalon.excalibur.datasource.J2eeDataSource" it points to
> > "org.apache.excalibur.datasource.J2eeDataSource".
> > 2. esql.xsl. In case when a connection is obtained from DataSource one
> > should not invoke setAutoCommit() method. Otherwise SQLException will be
> > thrown. Looking at esql.xsl, I've found that you catch any exceptions thrown
> > by this method but you rethrow RuntimeException which is incorrect. I don't
> > think you should throw any exception in this exception handler. See esql.xsl
> > line 362.
>
> I'm glad that works for you!
> I have applied your fixes, and am committing them now. (esql.xsl is a bit tricky
> in that it has to be updated in three repositories....)
This message is for Donald Ball:
I have not forgotten about Cocoon 1 version of esql.xsl. I am trying to get a
fresh copy of it from CVS, but my client is chugging for a long time. Once I
get it, I will commit the same change in Cocoon 1.
Reguarding the above statement # 2:
would it be propper of us to only setAutoCommit if we are manually declaring our
connection? I would think so--esp. since Avalon's DataSourceComponent manages
the AutoCommit correctly.
Re: javax.sql.DataSource
Posted by Berin Loritsch <bl...@apache.org>.
kesha wrote:
>
> Hi guys,
>
> I've tried to deploy cocoon into WL 6.0 server and use DataSource as a jdbc
> Connection factory. Doing that, I've found a couple of bugs. Could anybody
> to commit the following changes into CVS:
>
> 1. cocoon.roles, role name
> "org.apache.avalon.excalibur.datasource.DataSourceComponentSelector". The
> hint for j2ee points to the wrong class name. Insteed of
> "org.apache.avalon.excalibur.datasource.J2eeDataSource" it points to
> "org.apache.excalibur.datasource.J2eeDataSource".
> 2. esql.xsl. In case when a connection is obtained from DataSource one
> should not invoke setAutoCommit() method. Otherwise SQLException will be
> thrown. Looking at esql.xsl, I've found that you catch any exceptions thrown
> by this method but you rethrow RuntimeException which is incorrect. I don't
> think you should throw any exception in this exception handler. See esql.xsl
> line 362.
I'm glad that works for you!
I have applied your fixes, and am committing them now. (esql.xsl is a bit tricky
in that it has to be updated in three repositories....)
javax.sql.DataSource
Posted by kesha <ke...@cosite.com>.
Hi guys,
I've tried to deploy cocoon into WL 6.0 server and use DataSource as a jdbc
Connection factory. Doing that, I've found a couple of bugs. Could anybody
to commit the following changes into CVS:
1. cocoon.roles, role name
"org.apache.avalon.excalibur.datasource.DataSourceComponentSelector". The
hint for j2ee points to the wrong class name. Insteed of
"org.apache.avalon.excalibur.datasource.J2eeDataSource" it points to
"org.apache.excalibur.datasource.J2eeDataSource".
2. esql.xsl. In case when a connection is obtained from DataSource one
should not invoke setAutoCommit() method. Otherwise SQLException will be
thrown. Looking at esql.xsl, I've found that you catch any exceptions thrown
by this method but you rethrow RuntimeException which is incorrect. I don't
think you should throw any exception in this exception handler. See esql.xsl
line 362.
After this changes I was able to deploy my app without any problems. Good
work guys!!!
/kesha
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org