Ok, I think I have found the reason you end up creating new sessions
everytime. But that should not be specific to reportMethod() but all
WebDAV methods you call from WebdavResource.

Try putting your username and password into your URL. You can then
omit the Credentials.

There's a strange test in WebdavResource, that gets executed before
every method call to check if the current credentials have changed.
This method is broken if you don't put them into the URL. This check
could be omitted if the URL and userinfo within WebdavResource were
protected from foreign mutations. I would like to see these
restrictions introduced in the post 2.0 code as
1) I see no benefit in being able to change those parameters after a
   WebdavResource is being created.
2) you could easily cache the decoded path and name to avoid decoding
   the path on every call to getPath(), getName() and when executing a
   WebDAV method for the current resource.

Ingo

> Hi,
> 
> Here is an example of some test code I wrote:
> 
>         Credentials credentials = new 
> UsernamePasswordCredentials("luke", "password");
>         String url = 
> "http://localhost:8080/slide2-db/files/iplus/data/funds/";;
> 
>         WebdavResource wdr = new WebdavResource(url, credentials);
> 
>         wdr.reportMethod(wdr.getHttpURL(), 0);
>         wdr.reportMethod(wdr.getHttpURL(), 0);
> 
> This creates THREE sessions in Tomcat.  Adding another call to 
> reportMethod() creates a new session.
> 
> Any ideas?
> 
> I'm going to download 2.0 final now - hopefully this may fix it, but I'm 
> suspecting it won't.
> 
> 
> Cheers
> 
> Luke.
> -----
> 
> 
> Ingo Brunberg wrote:
> 
> >Sorry, but I cannot see why reportMethod() should cause a new session
> >to be created. Btw., it is an inconsistency in the API that those
> >methods take a HttpURL argument instead of a simple path string like
> >the other methods. That should be resolved in CVS HEAD soon.
> >
> >Coming back to the problem: The only methods that open a new session,
> >at least as far as I can see, are the optionsMethod() calls. Are you
> >sure you are not calling something like setHttpURL() before or after
> >invoking one of the report methods?
> >
> >Ingo
> >
> >  
> >
> >>Hi,
> >>
> >>I did a bit more investigate and found I had made a mistake.  It wasn't  
> >>getHttpURL() that was creating a new session, it was the methods of  
> >>WebdavResource that used the HttpURL I had got (for example  
> >>reportMethod) that were causing a new session to be created.
> >>
> >>So, it seems it is not getHttpURL() that is creating the session, but  
> >>instead methods such as reportMethod() that take a HttpURL as a  
> >>parameter.
> >>
> >>
> >>Cheers
> >>
> >>Luke.
> >>-----
> >>
> >>
> >>
> >>On 10 May 2004, at 18:15, Ingo Brunberg wrote:
> >>
> >>    
> >>
> >>>This is indeed worth investigating. Calling getHttpURL() should really
> >>>not create a new session. Maybe you can post a code snippet?
> >>>
> >>>Ingo
> >>>
> >>>      
> >>>
> >>>>After a bit more investigation, it seems that constructing a new  
> >>>>HttpURL or
> >>>>using the getHttpURL() method of WebdavResource also creates a new  
> >>>>session.
> >>>>
> >>>>Should it be doing this?
> >>>>
> >>>>Is there a way to avoid it doing so?
> >>>>
> >>>>There are some cases where I can see no way of doing what I want  
> >>>>without
> >>>>constructing a new WebdavResource or a HttpURL.
> >>>>
> >>>>
> >>>>Cheers
> >>>>
> >>>>Luke.
> >>>>-----
> >>>>
> >>>>
> >>>>
> >>>>Quoting luke noel-storr <[EMAIL PROTECTED]>:
> >>>>
> >>>>        
> >>>>
> >>>>>Hmm, either I misunderstood what you meant, or it doesn't quite fix  
> >>>>>things
> >>>>>the
> >>>>>way I expected.
> >>>>>
> >>>>>I now only construct one webdav resource in my code, however, after  
> >>>>>running
> >>>>>just
> >>>>>a few simple getMethods, propFindMethods and reportMethods 5  
> >>>>>sessions are
> >>>>>created when I expected only one to be created.
> >>>>>
> >>>>>Any further suggestions?
> >>>>>
> >>>>>
> >>>>>Cheers
> >>>>>
> >>>>>Luke.
> >>>>>-----
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>Quoting luke noel-storr <[EMAIL PROTECTED]>:
> >>>>>
> >>>>>          
> >>>>>
> >>>>>>Hi,
> >>>>>>
> >>>>>>I don't have a problem in terms of errors or crashes or anything;  
> >>>>>>however,
> >>>>>>            
> >>>>>>
> >>>>>I
> >>>>>          
> >>>>>
> >>>>>>was
> >>>>>>in fear of the rapidly increasing session count (into several  
> >>>>>>thousands
> >>>>>>after
> >>>>>>just a few calls to a servlet I had).
> >>>>>>
> >>>>>>I shall now recode based on your advice though - thank you for your  
> >>>>>>help.
> >>>>>>
> >>>>>>
> >>>>>>Cheers
> >>>>>>
> >>>>>>Luke.
> >>>>>>-----
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>Quoting Ingo Brunberg <[EMAIL PROTECTED]>:
> >>>>>>
> >>>>>>            
> >>>>>>
> >>>>>>>Do you actually have a problem with open sessions or is you  
> >>>>>>>interest
> >>>>>>>rather theoretical?
> >>>>>>>
> >>>>>>>As I explained some time ago, you should use WebdavResource in  
> >>>>>>>such a
> >>>>>>>way that you call a WebdavResource constructor only once in your
> >>>>>>>application. This way you have no more than one connection, so you
> >>>>>>>should hit no resource limits, hence my question above.
> >>>>>>>
> >>>>>>>The reason that WebdavResouce.close() does not really close the
> >>>>>>>connection is that this would lead to having to reconnect if a  
> >>>>>>>parent
> >>>>>>>or a child obtained by calling listWebdavResources() or
> >>>>>>>getChildResources() issues the next request.
> >>>>>>>
> >>>>>>>You may call this a design deficiency, but this is how you are
> >>>>>>>cuurently supposed to work with the client library.
> >>>>>>>              
> >>>>>>>
> >>>>>>-------------------------------------------------------------------- 
> >>>>>>-
> >>>>>>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]

Reply via email to