Re: [xmlblaster] debugging Firebird storage

[Michele <michele at laghi.eu>]

Hi Brad,

Brad Clements wrote:
> On 10 Oct 2006 at 23:07, Michele wrote:
> 
>> Hi Brad,
>> could it be that the name in the JdbcDriver.drivers property
>> org.firebirdsql.jdbc.FBDriver is not correct for your version of the
>> driver ? If not please replace it (or add it) to the property below.
>>
>> If this does not work remove all other drivers and let this only
>> driver.
> 
> Thanks for the suggestion.
> 
> However I did check the Jaybird docs again, org.firebirdsql.jdbc.FBDriver is the 
> correct class and I did try the system using org.firebirdsql.jdbc.FBDriver as the 
> only driver in the list.
> 
> I will have to get back to this in a few weeks, unless we move to some other 
> MOM.  I'm still hoping for an answer to two outstanding issues, the other 
> message I posted
> 
> java.lang.NullPointerException in 
> org.xmlBlaster.engine.dispatch.CbDispatchConnection.doSend
> 
> 
> and also I need a way for the xmlblaster to force ldap authentication, and I can't 
> rely on having the client tell me the authentication method to use.  I asked on this 
> list a few months back about this issue, but that thread didn't go anywhere.
> 
> It just seems really odd that xmlblaster a) allows the client to specify the auth 
> method, b) requires the client to specify the authentication method 
> (securityService/ at type)
> 
Nothing odd with a): if the server offers different authorization
methods it is a nice feature. b) of course shall not be required. The
hot potato at the moment is the fact that clients are allowed to log in
even if 'simple' is not activated on the server side. I am looking at
this issue right now and will come back.

Regards
Michele



> If I change from htpasswd to ldap, I'd have to redeploy 50 client apps! I can't  do 
> that.  
> 
> And if some hacker decides to play a game, I can't rely on them choose 
>  at type='ldap' or whatnot.. It just seems really strange design to me. My boss says 
> I need a resolution in 2 days. :-(
> 
> 
> 
> 
> 
> 
> 
>