This is solved. I had to make sure to order the newer, modified OpenBaseWOPKPlugIn framework above the EOAccess framework in the build path.
Tim UCLA GSE&IS On Jun 9, 2014, at 2:28 PM, Timothy Worman <[email protected]> wrote: > Hola from CA: > > Following up and looking for advice on this. I did follow this approach > (below) for naming of the OpenBasePlugIn class. I’ve added some new > expressions to the OpenBaseSynchronization factory to support functions that > are missing for migrations. So, in a migration where you alter the column > type, you’d call this: > > ERXMigrationColumn.setDataType(). In that method are these calls: > > EOSchemaSynchronization schemaSynchronization = (EOSchemaSynchronization) > _table.database().synchronizationFactory(); > NSArray<EOSQLExpression> expressions = > schemaSynchronization.statementsToConvertColumnType(_name, _table.name(), > null, new _ColumnType(externalType, scale, precision, width), options); > > The sync factory that is returned is an instance of > OpenBasePlugIn$OpenBaseSynchronizationFactory. However, the > statementsToConvertColumnType that I added to the update > OpenBaseSynchronizationFactory isn't called. This makes me think it is still > referencing the OpenBasePlugIn that is part of the WO 5.4.3 distribution. App > launch fails with: > > “Your EOSynchronizationFactory does not support the required 'convert column > type' operation." > > Any thoughts on why the newer plugin with changes might not be getting > called? Is it possible that migrations are running before the newer plugin is > loaded into the classpath? > > Tim > UCLA GSE&IS > > On May 28, 2014, at 1:42 PM, Chuck Hill <[email protected]> wrote: > >> The replacement plugins are in ERExtensions which is forced into the class >> path before any of the WO frameworks. As such any classes that they contain >> that have the same package and class names as in WO proper will render the >> original classes invisible to the JVM. >> >> Chuck >> >> >> >> On 2014-05-28, 1:13 PM, "David Avendasora" wrote: >> >> All of the other PlugIns (Oracle excluded) seem to use the same name as the >> one included in the WO binaries, but I do see your point about it possibly >> causing confusion for all the WO developers out there using OpenBase. >> >> … >> >> … >> >> … >> >> snk. snrk. cough. cough… >> >> Okay, seriously though, I think it would be best to use the expected name >> (OpenBasePlugIn) and use the same mechanisms that the other DB plugins use >> to keep there from being conflicts. >> >> Now, let me get back to my servlet-based D2JC project with vertical >> inheritance and sharedEC on SQLServer. >> >> Which reminds me, somewhere around here I have Chuck’s MicrosoftPlugIn… I >> should look at updating that and getting it into Wonder, too - as I promised >> I would … a couple years ago. >> >> :-) >> >> Dave >> >> >> On May 28, 2014, at 12:27 PM, Timothy Worman <[email protected]> wrote: >> >> I received permission to include a modified OpenBasePlugIn into Wonder. >> Thought I’d open this up to a best practice discussion here. Since the >> original plugin was bundled with the WO frameworks, my assumption is that >> the plugin class should be renamed - sth like EROpenBasePlugIn? By doing so >> we could eliminate any possible confusion. >> It was communicated to me that the plugin was an enhanced version of the one >> that shipped with WO. I have modified it to correct immediate issues with >> migrations in Wonder (including updates to WO 5.4 synchronization classes). >> This would also make it somewhat dependent on a version of Wonder that has >> been updated in the same fashion - which I also have and, if it passes >> muster, could be pulled into Wonder as well. >> Tim >> UCLA GSE&IS >> _______________________________________________ >> Do not post admin requests to the list. They will be ignored. >> Webobjects-dev mailing list ([email protected]) >> Help/Unsubscribe/Update your Subscription: >> https://lists.apple.com/mailman/options/webobjects-dev/webobjects%40avendasora.com >> This email sent to [email protected] >> >> >> ————————————————————————————— >> WebObjects - so easy that even Dave Avendasora can do it!™ >> ————————————————————————————— >> David Avendasora >> Senior Software Abuser >> Nekesto, Inc. >> >> >> >> >> >> >> >> _______________________________________________ >> Do not post admin requests to the list. They will be ignored. >> Webobjects-dev mailing list ([email protected]) >> Help/Unsubscribe/Update your Subscription: >> https://lists.apple.com/mailman/options/webobjects-dev/chill%40global-village.net >> >> This email sent to [email protected] > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list ([email protected]) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/webobjects-dev/lists%40thetimmy.com > > This email sent to [email protected]
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
