"Rafal Krzewski" <[EMAIL PROTECTED]> wrote:
> Please notice the .jdbc2. in driver's package path. I received
> jConnect 5.2 along with ASE 11.9.2, and it looks like they changed
> package layout. After making this changes and reloading Turbine I got
> CDNF exception on com.sybase.jdbc.SybDriver. This was kind of
> surprising, because I checked for all occurances of SybDriver in
> .properties. Grepping the sources revealed another reference to
> 'com.sybase.jdbc.SybDriver' in
> src/java/org/apache/turbine/util/db/pool/DB.java. I don't send a patch
> for this, because I believe it is a serious bug to have a config file
> option sliently overriden by hardcoded value, and this probably needs
> redesigning.
I just recently added the DBSybase.java class and modified DB.java and agree
with you. We should read the driver name from the TurbineResources.properties
file.
> I changed the string, touched DBSybase.java (it references
> DB.DRIVER_SYBASE) recompiled and reloaded Turbine and ... KABOOM!
>
> Exception: java.lang.Error: Error in BasePeer.initTableSchema(Visitor): The
> method com.sybase.jdbc2.tds.RowFormatToken.getTableName(56) has not been
> completed and should not be called.
[SNIPPED]
> As of version 5.2, ResultSetMetaData works just fine - after you run a
> 180kb TSQL script with lots of stored procedures that comes along with
> the distribution.
I don't belive you are correct. In the release notes for jconnect there are
specific methods that are not implemented since they require a change to the
TDS stream (hence the above exception). Sybase says all products will have to
change and don't excpect it until version 12.5 of the server product. Since
it is really a problem with the TDS stream, third-party JDBC driver vendors,
it seems, cannot implement these methods. While 5.2 has implemented a few
more than the 4.x version of the driver, there are still important ones
missing.
> We hacked a simple servlet for the purprose of testing jdbc and and
> MetaData stuff. It's ugly, yet may be usefull to somebody. Mail me if
> you want to have a look on it. I think about making Turbine/WebMacro
> version of it, so you can use it as comparative example ;)
If you search the email list archives you can find more information about this
problem. Sybase also has some newsgroups and if you search those you can get
the reply from the Sybase engineer.
Turbine's default database access for user
authorization/authentication/storage uses the Village database access class
library ( http://www.working-dogs.com/village ). This class library uses the
jdbc methods that Sybase did not implement. If you really wanted to hack a
way to use sybase with Turbine's default behavior, just hack Village to
support it. Unfortunetly, this means not using jdbc methods that correct
drivers implement, or ???
The other option is not to use the Peer classes in Turbine and implement your
own User object. The peer could then use database access that jconnect
supports. Since permissions and roles are also stored in a db, you'd need to
implement those also. You could check the FAQ and mailing list for
information on using other authentication methods.
The reason I added the DBSybase.java functionality was for connection pooling.
So if you are not using the JNDI/LDAP connection pooling features of 5.2, you
can still use Turbine's.
l8r,
jb
Jeff Brekke
mailto:[EMAIL PROTECTED]
http://sites.netscape.net/ekkerbj
____________________________________________________________________
Get your own FREE, personal Netscape WebMail account today at
http://webmail.netscape.com.
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
