Sorry - can't answer that one for sure. Does look a bit strange. I could only guess that it might be to do with classloading? I seem to remember that a class "abc.def.MyClass" loaded by classloader "A" is deemed to be different to the same class "abc.def.MyClass" loaded by classloader "B", so I would guess that this might lead to casting problems. I haven't used JNDI much apart from in the context of DBCP, so I'm not sure exactly how it works - could it maybe be using a different classloader to the one loading your servlet classes?
Then again that could be complete rubbish :) > -----Original Message----- > From: Roland Carlsson [mailto:[EMAIL PROTECTED] > Sent: Wednesday 27 October 2004 13:41 > To: TomcatUsers > Subject: Sv: GlobalNamingResouces used by other GlobalNamingResources > > > Hello Steve! > > I have done some trial and error and come to the following > (if not somewhat > shaky) conclusion. > > If I make the call to the datasource in the consturctor of my > object it will > fail, since the caller is the server itself and it has no context. > > If I make the call to the datasource as a method after have > looked up my > object and retrived as a "user" it will run in the context of the user > (web-app) and therefore work. Perhaps Yoav can confirm this? > > So, I manage to get my object...but get a strange class cast error.... > > This code: > > System.out.println(o); > se.alfamoving.file.db.FileIdGenerator fg = > (se.alfamoving.file.db.FileIdGenerator) o; > > Gives this output: > > [EMAIL PROTECTED] > java.lang.ClassCastException <snip/> > > > But I'll guess that I spelled badly somewhere :-/ The happy > moments never > seems to last :-) > > Thank you very much for your time and effort! > > Regards > Roland Carlsson > > > > Den 04-10-27 14.28, skrev "Steve Kirk" > <[EMAIL PROTECTED]>: > > > OK now I see your problem. I have the same issue. I've > worked around it > > with a bit of a hack I'm afraid, and just used the MySQL > non-jdbc solution. > > As you say I will pay the price for this sin later, if I > ever need to swap > > database. However I've taken a view that for my specific > situation, this is > > unlikely in the medium term. So instead of investing time > in making the > > code completely portable to another database, I've invested time in > > mitigating the impact by genericising my code so that there > is only one > > place I will need to make changes. (Essentially, I've > beanified all my > > database tables so that I have a single method that creates > rows in any > > table in the database and returns the ID). > > > > I think portability and re-use are worth investing time and > effort in, but > > there is a limit to that, and sometimes, you need to make > compromises and > > move on, otherwise you can spend days trying to work around > a problem that > > might never happen. > > > >> -----Original Message----- > >> From: Roland Carlsson [mailto:[EMAIL PROTECTED] > >> Sent: Wednesday 27 October 2004 13:03 > >> To: TomcatUsers > >> Subject: Sv: GlobalNamingResouces used by other > GlobalNamingResources > >> > >> > >> Hi Steve and thanks for you answer. > >> > >> Try the following scenario. > >> > >> The problem is to get back the primary key when doing an > >> insert. Say that > >> you have a master/slave relation between two tables. > >> > >> You insert a row into master. Then you are going to insert > a few rows > >> connected to the master into slave. How do you know the > >> id-number of your > >> master? > >> > >> I know that mysql has a non-jdbc soloution for this but since > >> one of our > >> general design goals are portable code...... So, we have > >> desided to take the > >> same apporach as Object-Relational Bridge. We created our own > >> id-generator > >> to handle the problem. But its has created a new set of > >> problems now when we > >> are going to use multiple web-apps and (in a not so distant > >> future) mutiple > >> servers. > >> > >> Regards > >> Roland Carlsson > >> > >> > >> > >> > >> Den 04-10-27 13.48, skrev "Steve Kirk" > >> <[EMAIL PROTECTED]>: > >> > >>> sorry, can't answer specific Q on whether you can access > >> datasource from > >>> generator. but it sounds like you are trying to uniquely > >> ID rows in a > >>> database? > >>> > >>> if so then the simplest way seems to be to use > >> auto_increment fields and let > >>> the database handle it. or are you saying that that isn'y > >> working - is this > >>> what you mean by "not supporting the database-generated > >> id-numbers"? if so > >>> please say more about why its not working. what database? > >> code sample? > >> > >> > >> > --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: > [EMAIL PROTECTED] > >> > >> > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
