Hi,
I plan to tag and push for a release Daemon 1.0.13 later today.
We have some regression, or better to say an old problem
which manifested with new version which requires a new release.
The fix was already confirmed by Tomcat folks.
Regards
--
^TM
---
Guten Morgen,
> +/**
> + * Use a custom {@link ClassLoader} for loading the class.
> + *
> + * @param classLoader the {@link ClassLoader} to load the class.
> + * @return the {@link ClassAccessor} for the class being loaded.
> + */
> ClassAccessor loadWithClassLoader(
Perhaps not for local file systems, but I would imagine that any kind of
distributed file system would have need of a socket timeout.
Cheers,
Mark
On Tue, Feb 5, 2013 at 1:59 PM, Gary Gregory wrote:
> On Tue, Feb 5, 2013 at 4:54 PM, Mark Fortner wrote:
>
> > Just out of curiousity, is there
On Tue, Feb 5, 2013 at 4:54 PM, Mark Fortner wrote:
> Just out of curiousity, is there a reason that socket timeouts shouldn't
> also apply to all file systems in general?
>
How does a socket timeout make sense for a local file system, ZIP, and so
on?
Gary
>
> Cheers,
>
> Mark
>
>
>
> On Tue,
Just out of curiousity, is there a reason that socket timeouts shouldn't
also apply to all file systems in general?
Cheers,
Mark
On Tue, Feb 5, 2013 at 8:58 AM, Gary Gregory wrote:
> Sure, make sure you base you patch on the latest from trunk.
>
> Gary
>
>
> On Tue, Feb 5, 2013 at 11:50 AM,
Hello list members,
We need to be able to specify socket timeouts in VFS for HTTP and
WebDAV in our project so that request will no hang for ever in certain
conditions.
I have modified the sources of HttpFileSystemConfigBuilder and
HttpClientFactory to be able to configure this in HttpClient.
D
Hi Simo,
2013/2/5 Simone Tripodi
> Guten Tag, Bene,
>
> > I personally try to avoid static imports.
> > Especially when you come to a legacy code base IMHO it makes the code
> > harder to understand.
>
> as BU2 user, would you write the following sentence
>
> on( testBean ).invoke( "setBool
Hi.
In the thread about "static import", Stephen noted that decisions on a
component's evolution are dependent on whether the future of the Java
language is taken into account, or not.
A question on the same theme also arose after the presentation of
Commons
Math in FOSDEM 2013.
If we assume t
Guten Tag, Bene,
> I personally try to avoid static imports.
> Especially when you come to a legacy code base IMHO it makes the code
> harder to understand.
as BU2 user, would you write the following sentence
on( testBean ).invoke( "setBooleanProperty" ).with( argument( new
Boolean( false )
FYI, the Project Lambda Streams code and JSR-310 in JDK 1.8 are both
written with static imports in mind. Moreover, with support for static
methods in interfaces being added, this is likely to increase as a
pattern. Those facts may or may not affect decisions in commons.
Stephen
On 4 February 20
Hey,
thanks for your feedback. It's interesting to see that there seem to be two
opposing opinions:
Some try to avoid static imports as much as possible, while others use them
if it makes the code "more fluent".
I found the Matt's comment especially useful, for pointing out, that we (as
developer
11 matches
Mail list logo
