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.
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.
> -----Original Message-----
> From: fusionreactor@googlegroups.com
> [mailto:fusionreactor@googlegroups.com] On Behalf Of dave
> Sent: Thursday, October 22, 2009 9:11 PM
> To: FusionReactor
> Subject: FusionReactor Group: No suitable driver available for
> MyDatabase_WRAPPED
> 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.
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:
> 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
> > -----Original Message-----
> > From: fusionreactor@googlegroups.com
> > [mailto:fusionreactor@googlegroups.com] On Behalf Of dave
> > Sent: Thursday, October 22, 2009 9:11 PM
> > To: FusionReactor
> > Subject: FusionReactor Group: No suitable driver available for
> > MyDatabase_WRAPPED
> > 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.
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:
> 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:
> > 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
> > > -----Original Message-----
> > > From: fusionreactor@googlegroups.com
> > > [mailto:fusionreactor@googlegroups.com] On Behalf Of dave
> > > Sent: Thursday, October 22, 2009 9:11 PM
> > > To: FusionReactor
> > > Subject: FusionReactor Group: No suitable driver available for
> > > MyDatabase_WRAPPED
> > > 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.
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.
> -----Original Message----- > From: fusionreactor@googlegroups.com > [mailto:fusionreactor@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
> 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.
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:
> 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: fusionreactor@googlegroups.com
> > [mailto:fusionreactor@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
> > 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.
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
On Oct 26, 1:48 am, David Stockton <david.j.stock...@gmail.com> wrote:
> 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:
> > 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: fusionreactor@googlegroups.com
> > > [mailto:fusionreactor@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
> > > 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.
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
On Oct 27, 10:10 am, dave <davede...@gmail.com> wrote:
> 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
> On Oct 26, 1:48 am, David Stockton <david.j.stock...@gmail.com> wrote:
> > 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:
> > > 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: fusionreactor@googlegroups.com
> > > > [mailto:fusionreactor@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
> > > > 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.
|
