You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by "Craig R. McClanahan" <cr...@apache.org> on 2002/01/25 20:44:22 UTC
Re: cvs commit: jakarta-struts/src/share/org/apache/struts/config
ConfigRuleSet.java
On Wed, 23 Jan 2002, Anthony Martin wrote:
> Date: Wed, 23 Jan 2002 14:01:41 -0800
> From: Anthony Martin <An...@TRAMS.com>
> Reply-To: Struts Developers List <st...@jakarta.apache.org>
> To: "'struts-dev@jakarta.apache.org'" <st...@jakarta.apache.org>
> Subject: Re: cvs commit:
> jakarta-struts/src/share/org/apache/struts/config ConfigRuleSet.java
>
> How can data-source properties be deprecated in 1.0? I didn't see any
> indication of that in either the examples or documentation or source code
> for that matter.
>
The "lib/struts-config_1_0.dtd" file (used to validate the format of your
configuration file) includes the following comment just above all the old
properties in the definition of the <data-source> element:
WARNING: The use of these attributes is deprecated. You
should use nested <set-property> elements to configure *all*
properties of your data source implementation.
> I know these documentation is hard to maintain,
Ted, we probably need to mention this in the HTML docs -- the info that is
in the DTD file comments will answer tons of user questions, but I'd bet
most users don't even know it is there.
> so what do I do? Here's my
> guess:
>
> <data-source>
> <set-property property="key" value="FOO" />
> <set-property property="autoCommit" value="false" />
> <set-property property="description" value="Foo DataBase" />
> <set-property property="driverClass"
> value="sun.jdbc.odbc.JdbcOdbcDriver" />
> <set-property property="maxCount" value="8" />
> <set-property property="minCount" value="0" />
> <set-property property="url" value="jdbc:odbc:demodata" />
> <set-property property="user" value="foo" />
> <set-property property="password" value="bar" />
> </data-source>
>
You've got it right. And this works today with 1.0 and 1.0.1.
>
> Anthony
>
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-struts/src/share/org/apache/struts/config
ConfigRuleSet.java
Posted by Ted Husted <hu...@apache.org>.
"Craig R. McClanahan" wrote:
> Ted, we probably need to mention this in the HTML docs -- the info that is
> in the DTD file comments will answer tons of user questions, but I'd bet
Will do. The resource page is also *way* over due. Have some time block
out again this weekend. Had some technical difficulties last week, so
didn't get much done, but things seem to be humming again.
And congrats on the Web Services. I'll looking forward to taking the EA
for a spin. With you as the implementation engineer, I'm of course
expecting it all to work flawlessly :0)
-Ted.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: cvs commit: jakarta-struts/src/share/org/apache/struts/config ConfigRuleSet.java
Posted by Anthony Martin <an...@trams.com>.
My example shows a jdbc:odbc driver, but we use InterBase in development and
production. I test as many drivers as I can set up. Maybe I should check
out PostgreSQL.
There is no stack trace because the problem I'm experiencing is that calling
servlet.getServletContext().getAttribute("xxx") returns null. I even tried
the deprecated findDataSource("xxx") method, I get the same result.
Out of curiosity, I added a break point to the ActionServlet
initApplicationDataSources() method (thanks to JBuilder5 from Borland,
http://www.borland.com/).
I stepped through the population of the DataSourceConfig array and found
that it only went though the first datasource. So, I tried
findDataSource(null) and it worked as expected in that it returned a
not-null datasource.
So it appears the root problem is that initApplicationDataSources is not
stepping through all of the datasources listed in my struts-config.xml and
that putting only one data-source in there is a workaround. Using PoolMan
is another workaround if I *have* to have multiple data-sources.
Hope this helps find the problem.
Anthony
-----Original Message-----
From: Craig R. McClanahan [mailto:craigmcc@apache.org]
Sent: Friday, January 25, 2002 12:11 PM
To: Struts Developers List
Subject: RE: cvs commit:
jakarta-struts/src/share/org/apache/struts/config ConfigRuleSet.java
On Fri, 25 Jan 2002, Anthony Martin wrote:
> Date: Fri, 25 Jan 2002 11:59:43 -0800
> From: Anthony Martin <an...@trams.com>
> Reply-To: Struts Developers List <st...@jakarta.apache.org>
> To: Struts Developers List <st...@jakarta.apache.org>
> Subject: RE: cvs commit:
> jakarta-struts/src/share/org/apache/struts/config ConfigRuleSet.java
>
> Yes, I totally missed it.
Reviewing the HTML docs, we don't have any mention of it, so this isn't
totally unexpected :-(.
> Anyway, changing over to the set-properties
> allows my ActionServlet to start again, but the data-sources still don't
> actually work the way they used to. It has something to do with the
> GenericDataSource finding the driver string null.
>
I take it you are using a recent nightly build? It's been working for me
with GenericDataSource, talking to a Postgres database. Could you post
the stack trace that you get at startup time?
One other thing to keep in mind is that the JDBC-ODBC driver isn't really
designed to deal with web-based applications -- it has thread safety
issues. But that's a different issue than a startup failure.
> My choices are to drop back to the build that works and loose those nifty
> DynaBeans, or to check out PoolMan. Just not sure about the Lesser GPL.
:P
>
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: cvs commit: jakarta-struts/src/share/org/apache/struts/config
ConfigRuleSet.java
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Fri, 25 Jan 2002, Anthony Martin wrote:
> Date: Fri, 25 Jan 2002 11:59:43 -0800
> From: Anthony Martin <an...@trams.com>
> Reply-To: Struts Developers List <st...@jakarta.apache.org>
> To: Struts Developers List <st...@jakarta.apache.org>
> Subject: RE: cvs commit:
> jakarta-struts/src/share/org/apache/struts/config ConfigRuleSet.java
>
> Yes, I totally missed it.
Reviewing the HTML docs, we don't have any mention of it, so this isn't
totally unexpected :-(.
> Anyway, changing over to the set-properties
> allows my ActionServlet to start again, but the data-sources still don't
> actually work the way they used to. It has something to do with the
> GenericDataSource finding the driver string null.
>
I take it you are using a recent nightly build? It's been working for me
with GenericDataSource, talking to a Postgres database. Could you post
the stack trace that you get at startup time?
One other thing to keep in mind is that the JDBC-ODBC driver isn't really
designed to deal with web-based applications -- it has thread safety
issues. But that's a different issue than a startup failure.
> My choices are to drop back to the build that works and loose those nifty
> DynaBeans, or to check out PoolMan. Just not sure about the Lesser GPL. :P
>
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: cvs commit: jakarta-struts/src/share/org/apache/struts/config ConfigRuleSet.java
Posted by Anthony Martin <an...@trams.com>.
Yes, I totally missed it. Anyway, changing over to the set-properties
allows my ActionServlet to start again, but the data-sources still don't
actually work the way they used to. It has something to do with the
GenericDataSource finding the driver string null.
My choices are to drop back to the build that works and loose those nifty
DynaBeans, or to check out PoolMan. Just not sure about the Lesser GPL. :P
-----Original Message-----
From: Craig R. McClanahan [mailto:craigmcc@apache.org]
Sent: Friday, January 25, 2002 11:44 AM
To: Struts Developers List
Subject: Re: cvs commit:
jakarta-struts/src/share/org/apache/struts/config ConfigRuleSet.java
On Wed, 23 Jan 2002, Anthony Martin wrote:
> Date: Wed, 23 Jan 2002 14:01:41 -0800
> From: Anthony Martin <An...@TRAMS.com>
> Reply-To: Struts Developers List <st...@jakarta.apache.org>
> To: "'struts-dev@jakarta.apache.org'" <st...@jakarta.apache.org>
> Subject: Re: cvs commit:
> jakarta-struts/src/share/org/apache/struts/config ConfigRuleSet.java
>
> How can data-source properties be deprecated in 1.0? I didn't see any
> indication of that in either the examples or documentation or source code
> for that matter.
>
The "lib/struts-config_1_0.dtd" file (used to validate the format of your
configuration file) includes the following comment just above all the old
properties in the definition of the <data-source> element:
WARNING: The use of these attributes is deprecated. You
should use nested <set-property> elements to configure *all*
properties of your data source implementation.
> I know these documentation is hard to maintain,
Ted, we probably need to mention this in the HTML docs -- the info that is
in the DTD file comments will answer tons of user questions, but I'd bet
most users don't even know it is there.
> so what do I do? Here's my
> guess:
>
> <data-source>
> <set-property property="key" value="FOO" />
> <set-property property="autoCommit" value="false" />
> <set-property property="description" value="Foo DataBase" />
> <set-property property="driverClass"
> value="sun.jdbc.odbc.JdbcOdbcDriver" />
> <set-property property="maxCount" value="8" />
> <set-property property="minCount" value="0" />
> <set-property property="url" value="jdbc:odbc:demodata" />
> <set-property property="user" value="foo" />
> <set-property property="password" value="bar" />
> </data-source>
>
You've got it right. And this works today with 1.0 and 1.0.1.
>
> Anthony
>
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>