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