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 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]

Reply via email to