My guess is that it's a problem with the MySQL database permissions.
You might try turning on logging on the db.
-steve
On Jun 25, 2009, at 10:40 AM, John Pollard wrote:
Dave/Timo/Chuck, thank you for your replies.
I am not using Wonder.
I have added logging of the DB connection parameters in the (first
and only) model within the EOModelGroup, and the bits I set seem to
come out as expected:
driver = "com.mysql.jdbc.Driver"; URL = "jdbc:mysql://localhost/
MPDB2?
user
=
root
&capitalizeTypeNames=true&useUnicode=true&characterEncoding=UTF-8"; }
(I cut out the password)
The log line spitting out the whole model connection dictionary is
huge, but the above seem to be key bits contained in it.
Unfortunately I can't compare with the previous application release
because that didn't have the logging line in it. If I get my
powermac back from the repairers, I could add the log line to
compare. But the key values look right to me.
This same EOModel framework works ok with the previous build of the
application. To me that seems to show that the model framework and
settings is not under suspicion itself as I can use it and it works.
The same EOModel framework has always worked fine, connecting to a
mysql database. The problem below is when the new build application
is used, so it seems to be a problem with how that application makes
use of my model framework rather than the model framework itself. So
the Properties idea seems quite a good one as that seems to be one
way to tell the application to ignore the framework connection info.
Do we know of any changes in wolips with picking up db connection
properties?
All works in development ok, so it is a deployment issue.
John
On 25 Jun 2009, at 17:41, David Avendasora wrote:
Can you paste the connection information here from the EOModel?
What type of DB is it? Is there any way that there are some
permissions on the DB that keep this instance from connecting?
Dave
On Jun 25, 2009, at 12:34 PM, John Pollard wrote:
Ah yes, I was just reading the thread about Properties on the dev
list, but no, the app Properties file only has commented out
property lines in it. Thanks for the idea though.
On 25 Jun 2009, at 17:01, David Avendasora wrote:
On Jun 25, 2009, at 8:07 AM, John Pollard wrote:
Hi List,
I maintain a separate framework containing the model definition
which has worked well.
My powerpc g5 recently died so I have switched to another Mac.
In development all is well, but on deployment I now get this:
...
[2009-6-25 11:42:8 GMT] <main> Model loaded is: <EOModelGroup
( ( Inrax,
file:/Library/Frameworks/InraxEOModel.framework/Resources/
Inrax.eomodeld ) )>
...
[2009-6-25 11:42:8 GMT] <main> Waiting for requests...
[2009-6-25 11:42:8 GMT] <MPMallSessionMonitor> An exception
occurred while trying to open a channel: N/A
Exception in thread "MPMallSessionMonitor"
java.lang.IllegalStateException: _obtainOpenChannel --
com.webobjects.eoaccess.EODatabaseContext
com.webobjects.eoaccess.eodatabasecont...@1e037a: failed to open
database channel. Check your connection dictionary, and ensure
your databa
se is correctly configured.
at
com
.webobjects
.eoaccess
.EODatabaseContext._obtainOpenChannel(EODatabaseContext.java:1967)
at
com
.webobjects
.eoaccess
.EODatabaseContext
._objectsWithFetchSpecificationEditingContext
(EODatabaseContext.java:3054)
...
The first line correctly shows the InraxEOModel.framework where
the model is lurking but then later it fails to connect. Under
what circumstances might the model framework be found ok, but
the database connection fail (when I know the database is ok)?
I don't think the fault lies with the model framework because I
can use this newly deployed framework with the previously
deployed applications and it works fine.
So something must have changed in the way the newly built
application tries to do the database connection (works in
development, not in deployment).
Is there anything in the application's Properties file that is
overriding the connection info?
Is there any more logging I can do, or checks within the
deployed application files to see what is causing the failure.
I have moved to the latest stable wolips which may be one
difference, though I was already on the hotness.
Thanks,
John
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-deploy mailing list (Webobjects-deploy@lists.apple.com
)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-deploy/webobjects%40avendasora.com
This email sent to webobje...@avendasora.com
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-deploy mailing list (Webobjects-deploy@lists.apple.com
)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-deploy/webobjects%40avendasora.com
This email sent to webobje...@avendasora.com
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-deploy mailing list (Webobjects-
dep...@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-deploy/steveps%40me.com
This email sent to stev...@me.com
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-deploy mailing list (Webobjects-deploy@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-deploy/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
