Right. That message was concerning non-JNDI data sources, which is why I have to wire up connection managers in that example. If you're using JNDI it's a lot simpler.
Derek On Wed, Oct 21, 2009 at 2:19 PM, opyate <[email protected]> wrote: > > Thanks Derek. > > I also just found this: > > http://groups.google.com/group/liftweb/browse_thread/thread/e75046eaf215e97/259da9d9ef22ca7a?lnk=gst&q=%22extends+connectionmanager%22# > > > > On Oct 21, 9:15 pm, Derek Chen-Becker <[email protected]> wrote: > > I think that you're making this more complicated that it needs to be, > > although I may be misunderstanding the question. The ConnectionIdentifier > > trait has a jndiName val on it. If you specify a valid JNDI name for that > > val, then you don't need to wire up a connection manager for it. You can > > simply do things like: > > > > object MyConnOne extends ConnectionIdentifier { val jndiName = > > "jdbc/ConnOne" } > > object MyConnTwo extends ConnectionIdentifier { val jndiName = > > "jdbc/ConnTwo" } > > > > // Wire up a default > > DB.defineConnectionManager(DefaultConnectionIdentifier, DerbyDBVendor) > > > > DB.use(MyConnOne) { conn => > > DB.exec(conn) { results => ... } > > > > } > > > > Lift will automatically handle retrieving the data source via JNDI if you > > specify a ConnectionIdentifier and you don't have a connection manager > > defined. > > > > Derek > > > > > > > > On Wed, Oct 21, 2009 at 10:38 AM, opyate <[email protected]> wrote: > > > > > Hello Lift committers, > > > > > I have a quick question about defining a datasource. I usually do it > > > like this: > > > > > DefaultConnectionIdentifier.jndiName = "jdbc/myApp" > > > // use default internal Derby DB if there's not already a JNDI > > > connection defined > > > if (!DB.jndiJdbcConnAvailable_?) { // looks at > > > DefaultConnectionIdentifier > > > Log.warn("No JNDI configured - using default built-in Derby > > > database.") > > > DB.defineConnectionManager(DefaultConnectionIdentifier, > > > DerbyDBVendor) > > > } > > > > > Is DerbyDBVendor in this case a fallback datasource? (Presumably it > > > is, if the JNDI lookup is not available...) > > > > > If so, this leads to my next question, relating to defining extra > > > (i.e. non-default) datasources. > > > > > The only way (it seems) for me to do it, is by using: > > > > > DB.defineConnectionManager(CustomConnId1, SomeDBVendor1) > > > DB.defineConnectionManager(CustomConnId2, SomeDBVendor2) // > > > CustomConnId1/2 points to defined JNDI lookups > > > > > Is there a way to define custom datasources without specifying a > > > fallback SomeDBVendor1, SomeDBVendor2, etc? > > > I couldn't see anything obvious in the latest checkout of DB.scala > > > > > At the moment I'm forced to define these fallbacks, and when my app > > > context reloads, poor Derby steps on its own toes: > > > > > Caused by: java.nio.channels.OverlappingFileLockException > > > at sun.nio.ch.FileChannelImpl$SharedFileLockTable.checkList > > > (FileChannelImpl.java:1170) > > > at sun.nio.ch.FileChannelImpl$SharedFileLockTable.add > > > (FileChannelImpl.java:1072) > > > at sun.nio.ch.FileChannelImpl.tryLock(FileChannelImpl.java:878) > > > at java.nio.channels.FileChannel.tryLock(FileChannel.java:962) > > > at > org.apache.derby.impl.io.DirFile4.getExclusiveFileLock(Unknown > > > Source) > > > > > I understand that SomeDBVendor1/2 could contain my db connection > > > details, but I don't want to have db connection details specified in > > > ConnectionManager instances in my code, and would rather keep them in > > > JNDI lookups, and said ConnectionManager instances seems to be > > > compulsory at this stage. > > > > > Please shed some light - I might be missing the boat again > > > completely :-) > > > > > Ultimately I'd like to have the same control over my extra datasources > > > than I do over DefaultConnectionIdentifier. > > > > > Thanks, > > > Juan > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~----------~----~----~----~------~----~------~--~---
