Re: Different client properties on the same JVM

On Fri, Oct 21, 2011 at 12:50 PM, Javier Mendez Vasquez
<[email protected]> wrote:
> Hi Mike,
>
> Thanks for your response.
>
> What I'm really looking for is changing user credentials (such as username, domain and password) used to connect to file shares. If properties were not static, I could have more than one thread doing stuff to multiple file shares at the same time (each share may require different credentials).

Hi Javier,

You should always use jcifs.smb.NtlmPasswordAuthentication objects to
hold credentials. You can pass those to the SmbFile constructors and
thus credentials are not static. The
jcifs.smb.client.{domain,username,password} properties are only used
to specify the "default" credentials.

Mike

-- 
Michael B Allen
Java Active Directory Integration
http://www.ioplex.com/

> -----Original Message-----
> From: Michael B Allen [mailto:[email protected]]
> Sent: Thursday, October 20, 2011 10:48 PM
> To: Javier Mendez Vasquez
> Cc: [email protected]
> Subject: Re: [jcifs] Different client properties on the same JVM
>
> On Thu, Oct 20, 2011 at 8:32 PM, Javier Mendez
> <[email protected]> wrote:
>> Hi,
>>
>> I´m facing a problem with the client properties. I want to use two (or more)
>> different sets of properties on the same Java virtual machine.
>>
>> Is my understanding, that in the way JCIFS is built at the moment, it will use a
>> static reference to the client properties (jcifs.Config) and then the first time
>> classes are referenced those properties are loaded.
>>
>> What is the purpose behind that?
>
> Hi Javier,
>
> Windows clients cannot dynamically change their lmcompatibilitylevel
> or WINS server or response timeout or whatever you might set through
> jcifs.Config. So it was not considered important for JCIFS to be able
> to change these properties in a non-global way either. But ...
>
>> Also, are there any plans of changing the way properties are managed in the
>> future? If no, then how much effort (if that is possible of course) would be
>> required to make that change?
>
> Yes. This has been a desirable feature for a while. But it would
> require considerable restructuring. It's really a 2.0 feature. But
> that is on hold indefinitely because I just don't have a lot of "Free"
> time these days. We're in maintenance mode right now and even that is
> limited mostly to significant bugs.
>
> Thanks for the feedback.
>
> Mike