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]
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]
Sv: GlobalNamingResouces used by other GlobalNamingResources
Thank you very much both Steve and Yoav! The general advice from that last few messages are, don't have your classes in two places, it will cause problem. And postpone JNDI-calls from the constructor if you are going to put them in the GlobalNamingContext (atleast if they are going to stay in the same server). Regards Roland Carlsson Den 04-10-27 15.02, skrev Shapira, Yoav [EMAIL PROTECTED]: 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
