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-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
