On Mar 9, 2008, at 7:17 AM, Mike Schrag wrote:
> I'm actually not sure how your app ran when you deployed it if you
> didn't include JavaEOAccess in your build path? So while it's
> technically not required to BUILD your project, it's required to RUN
> your project, so you should have already had JavaEOAccess?
It is in the app, not the framework project's build path. The
eomodel is in the framework project. I tend to reference only those
frameworks and jars necessary to build a particular project.
>> Yet another exception was eliminated by adding the FrontBase JDBC
>> driver, frontbasejdbc.jar, to the build path.
> ... and here, except that generally people have frontbasejdbc.jar
> in /Library/Java/Extensions and it should be picked up
> automatically. Do you not have that?
It's in /Library/WebObjects/Extensions. I tend to put jars used only
by WO apps in /Library/WebObjects/Extensions and jars used by non-WO
Java processes in /Library/Java/Extensions.
>> To eliminate another exception, I had to connect via VPN to the
>> network on which the database host lives (I wonder why Entity
>> Modeler must access the database itself to generate SQL).
> Talk to your friendly neighborhood EOF about this one. EOModeler
> had this same restriction except that it required you to be able to
> connect to the database right from the start.
I don't recall that behavior, so I booted Tiger on a portable with no
Internet connection. I opened an eomodel whose connection dictionary
specified an unreachable remote database server. EOModeler appeared
to open more slowly than normal, maybe because it was trying to
connect to the database server in the eomodel. However, the eomodel
did open with no database connection. I guess it did so even though
it could not get the jdbc2info from the server, maybe instead relying
on the jdbc2info already in the eomodel. I was able to do anything
that one would expect to be able to do without a database connection.
However, when I saved the eomodel after I changed the connection
dictionary, an alert panel warned that a connection to the database
server failed and refused to save my changes.
> If you notice, Entity Modeler doesn't give you a list of external
> types like EOModeler did. That's because I didn't want to require
> that you had to have access to your database just to make a model
> (like EOM required to get jdbc2Info).
Maybe Entity Modeler could behave like EOModeler appears to behave:
attempt to connect to the DB server in the connection dictionary, but
after a brief period, give up connecting if no connection is made and
use any existing jdbc2info to create a list of external types.
> However, I can't escape it for SQL gen ... EOF has to be able to
> fire up a connection to get jdbc2Info to be able to get external
> types. I've always felt this was stupid. The plugins SHOULD be
> able to return their external type information without a db
> connection, but I suppose you could argue that external types could
> change across versions, but it's perfectly acceptable to me that you
> have to update your plugin if you update your db version.
Could Entity Modeler attempt to connect but give up if no connection
occurs within a brief time-out period? If a time-out occurs, it could
instead get the jdbc2info from the plugin.
Aloha,
Art
This archive was generated by hypermail 2.0.0 : Mon Mar 10 2008 - 17:04:58 EDT