No suitable driver available for MyDatabase_WRAPPED

[dave]

I'm trying to get the JDBC wrapper working for my datasource but get
the following error:

"Connection verification failed for data source: MyDatabase_WRAPPED
java.sql.SQLException: No suitable driver available for
MyDatabase_WRAPPED, please check the driver setting in resources file,
error: com.intergral.fusionreactor.jdbc.Wrapper
The root cause was that: java.sql.SQLException: No suitable driver
available for MyDatabase_WRAPPED, please check the driver setting in
resources file, error: com.intergral.fusionreactor.jdbc.Wrapper"


I've read of a similar issue using mySQL, but I'm using SQL 2005 and
can't seem to get it to work. I have CF9 installed in multiple server
mode, so I have several instances running. I used the FR wrapper tool
to create the initial wrapping and running FR 3.5.0. Otherwise, I'm
using the default setup.


Data & Services > Datasources > Other:

Name: myDatabase_WRAPPED
JDBC URL : jdbc:fusionreactor:wrapper:{jdbc:macromedia:sqlserver://
localhost:
1433;databaseName=myDatabase;SelectMethod=direct;sendStringParametersAsUnicode=false;querytimeout=900;MaxPooledStatements=999};driver=macromedia.jdbc.MacromediaDriver;name=myDatabase

Driver Class: com.intergral.fusionreactor.jdbc.Wrapper
Driver Name: FusionReactor Wrapper (MSSQLServer)



Thoughts?

[charlie arehart]

Hmm, will be interested to hear the Intergral guys' take on this.

The fact that you're on 3.5 should resolve the typical problem like this
that people used to get, prior to their applying a fix that was released for
3.0.1.

But I see something about your JDBC URL that does make me wonder. You show
using the setting:

driver=macromedia.jdbc.MacromediaDriver;

That shouldn't be needed. But then it is the name of the driver used by CF
for SQL Server DSNs (if one digs into the underlying neo-datasource.xml file
that the CF admin updates for DSNs), so I don't think it's an error to refer
to it. But I do wonder why might happen if you removed it. Did you add it
yourself?

You say you "used the FR wrapper tool to create the initial wrapping and
running FR 3.5.0. Otherwise, I'm using the default setup." So I don't know
if this is the result of the "initial wrapping" you refer to. When you then
say "the default setup", that makes me wonder if you mean you got info for
settings out of the manual, which has a section that shows example settings
for different databases. Another section instead suggests (as I recommend)
getting the settings from the current datasource config, using the "settings
summary" feature, and using those in the JDBC URL.

I wonder also if something could be up with the multiple instances setup
that could be confusing things. To be clear, had you previously installed FR
3 or 3.0.1 on your server? I ask because you may have moved various jars
around for solving problems then that may not be needed now. Another problem
is that people sometimes rename jars from something.jar to
something-old.jar, which is a mistake. Java could still read the "old" jar,
as it doesn't pay attention to the file name, just whether it's a .jar file.

Indeed, unless you never ever installed FR on the box, you may want confirm
that it's is really running 3.5 as you say. You can click on the
fusionreactor logo in the top right of the admin interface, and the page it
shows has the version number in text near the bottom of the page.

Hope that helps.

/charlie

[dave]

I'm setting up a new server with cf9 enterprise version in multi-
server mode, windows 2008, IIs7.5 and FR 3.5.0 (Revision: 3.5.0,
Build: FusionReactor.74.14844). This is a fresh install of all of
those. I used the "FusionReactor JDBC Wrapper Tool - v0.8" provided by
InterGral to do the "wrapping". It created the JDBC URL exactly as:

"jdbc:fusionreactor:wrapper:{jdbc:macromedia:sqlserver://localhost:

1433;databaseName=myDatabase;SelectMethod=cursor;sendStringParametersAsUnicode=false;querytimeout=900;MaxPooledStatements=999};driver=macromedia.jdbc.MacromediaDriver;name=myDatabase"

Here is the JDBC URL before being "wrapped" by the FusionReactor JDBC
Wrapper Tool that's in the setting summary:

"jdbc:macromedia:sqlserver://localhost:
1433;databaseName=myDatabase;SelectMethod=cursor;sendStrin
gParametersAsUnicode=false;querytimeout=900;MaxPooledStatements=999"


I've also tried removing the driver=macromedia.jdbc.MacromediaDriver
with no luck.

-Dave

On Oct 23, 11:34 am, "charlie arehart" <charlie_li...@carehart.org>
wrote:

> > Thoughts?- Hide quoted text -
>
> - Show quoted text -

[dave]

OK, I seemd to have been able to resovle the error.

It appears that FR placed a fusionreactor.jar in each of the instances
SERVER-INF\lib (...\JRun4\servers\InstanceA1\SERVER-INF\lib)
directory. Maybe they got carried over from the cfusion root when I
created the new instances?? This is not where the database jar files
are, so I deleted all the fusionreactor.jar files and moved 1 into the
JRun4\lib directory with all the other jar files are and then
restarted CF. This seems to have resolved my issue and I can still
monitor all my instances. I'll have to see if this creates any other
issues, but at the moment, it seems to be working.

-Dave

On Oct 23, 3:57 pm, dave <davede...@gmail.com> wrote:
> I'm setting up a new server with cf9 enterprise version in multi-
> server mode, windows 2008, IIs7.5 and FR 3.5.0 (Revision: 3.5.0,
> Build: FusionReactor.74.14844). This is a fresh install of all of
> those. I used the "FusionReactor JDBC Wrapper Tool - v0.8" provided by
> InterGral to do the "wrapping". It created the JDBC URL exactly as:
>
> "jdbc:fusionreactor:wrapper:{jdbc:macromedia:sqlserver://localhost:

> 1433;databaseName=myDatabase;SelectMethod=cursor;sendStringParametersAsUnic­ode=false;querytimeout=900;MaxPooledStatements=999};driver=macromedia.jdbc.­MacromediaDriver;name=myDatabase"

> > - Show quoted text -- Hide quoted text -

[charlie arehart]

Thanks for the clarifications on the earlier note. Interesting to hear it
still didn't work then.

As for the later one, it's good to hear if that solved it, but I'll say that
on my multiserver deployment I also have the fusionreactor.jar in each
instances server-inf/lib dir. That's actually what led me to propose whether
it may have been that you had more than one jar there (like an older one).

Since it works for me with them in each instance, I'll look forward to
hearing from the Intergral folks about whether that's the way it should be,
or if your putting it in the central jrun4/lib may be better (or worse, for
some reason you may not yet see) for us running multiserver mode. I would
wonder if your moving it manually might make a later attempt to update (such
as to the new 3.5.1 as an example) not work, if the FR installer's not
expecting you to have moved the file.

Still, I realize your first focus is just getting it working. I'm sure the
guys will help sort it out in the best way for all.

/charlie

> -----Original Message-----
> From: fusion...@googlegroups.com
> [mailto:fusion...@googlegroups.com] On Behalf Of dave
> Sent: Friday, October 23, 2009 7:51 PM
> To: FusionReactor
> Subject: FusionReactor Group: Re: No suitable driver available for
> MyDatabase_WRAPPED
>
>

[David Stockton]

Hi,

The fusionreactor.jar file on a multi-instance server should indeed
live inside each instance by default:
eg: \JRun4\servers\<instance name>\SERVER-INF\lib\fusionreactor.jar

The error you posted seems to suggest that the fusionreactor.jar file
was not available to the ClassLoader used. If everything is a default
setup this should not be the case. Did you alter any of the class
paths or any other settings in the "jvm.config" file? Can you check
for duplicates in the classpath by searching the entire JRun4 folder
for "fusionreactor.jar"? How did you install FusionReactor - using the
Windows installer?

Running the FusionReactor Windows installer to perform updates will
not be able to upgrade "fusionreactor.jar" in its new, unexpected
location. However, you will still be able to upgrade following the
manual upgrade instructions which are quite short (
http://www.fusion-reactor.com/fr/manualupdate.cfm ).

One possible issue you may run into is if you attempt to use the
"Instance Manager" function of the Enterprise edition of FusionReactor
to install FusionReactor into another instance. You will find that it
places a new "fusionreactor.jar" inside the instances SERVER-INF
folder which would leave you with two copies in your classpath. This
could cause conflicts between the two and thus it would be better if
you could resolve the initial issue. However, other functionality of
the application server and FusionReactor should not be impacted by
keeping "fusionreactor.jar" in this higher level location.

@Charlie: The JDBC wrapper helper tool adds the "driver=" parameter to
all types of datasources it wraps, whether it's the Macromedia driver
or otherwise.

Many Thanks,
David Stockton
Fusion Support Team

On Oct 24, 12:00 am, "charlie arehart" <charlie_li...@carehart.org>
wrote:

[dave]

Ok, I put them back in the default directory and agree it's probably a
classpath issue. I was looking at my jvm.config file and the classpath
looks like:
java.class.path={application.home}/servers/lib,{application.home}/
servers/lib,{application.home}/servers/cfusion/cfusion-ear/cfusion-war/
WEB-INF/cfusion/lib/oosdk/classes,{application.home}/servers/cfusion/
cfusion-ear/cfusion-war/WEB-INF/cfusion/lib/oosdk/lib,
{application.home}/lib,{application.home}/servers/cfusion/cfusion-ear/
cfusion-war/WEB-INF/lib

Can someone post their default jvm.config file for CF9 so I can
compare and see if mine is differant?

-Dave

> > > -Dave- Hide quoted text -

[dave]

I added "{application.home}/servers/cfusion/SERVER-INF/lib" to my
classpath since I didn't see it listed and that also seemed to fix it,
but maybe someone has the best approach?

-Dave

> > - Show quoted text -- Hide quoted text -