I'm not sure if this will solve it or is even accurate - but probably worth you checking out. Specifically, look at msterjev's post re use of URLClassLoader near the bottom of the thread: http://www.experts-exchange.com/Programming/Programming_Languages/Java/Q_207 10542.html
> -----Original Message----- > From: Shapira, Yoav [mailto:[EMAIL PROTECTED] > Sent: Wednesday 27 October 2004 14:03 > To: Tomcat Users List > Subject: RE: GlobalNamingResouces used by other GlobalNamingResources > > > > Hi, > Yeah, Steve's advice on classloading is right on the mark... I don't > have time to check this out in depth, but I'd be surprised if he's > wrong. com.foo loaded from common/lib is not the same as > com.foo loaded > from WEB-INF/lib. > > Yoav Shapira http://www.yoavshapira.com > > > >-----Original Message----- > >From: Steve Kirk [mailto:[EMAIL PROTECTED] > >Sent: Wednesday, October 27, 2004 8:58 AM > >To: 'Tomcat Users List' > >Subject: RE: GlobalNamingResouces used by other GlobalNamingResources > > > >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] > > > > > This e-mail, including any attachments, is a confidential > business communication, and may contain information that is > confidential, proprietary and/or privileged. This e-mail is > intended only for the individual(s) to whom it is addressed, > and may not be saved, copied, printed, disclosed or used by > anyone else. If you are not the(an) intended recipient, > please immediately delete this e-mail from your computer > system and notify the sender. Thank you. > > > --------------------------------------------------------------------- > 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]
