This wont harm. Do it.

About the problem in this thread - please create a quickstart and
attach it to Jira.

On Mon, Aug 8, 2011 at 12:54 PM, Peter Ertl <pe...@gmx.org> wrote:
> Well, I _did_ follow the development ;-)
>
> Just made me wonder just from looking at 'open...' that there's no close.
>
> Maybe we need to do this:
>
>
>                // otherwise open the url and proceed
>                URLConnection connection = url.openConnection();
> // -----------------------
>                connection.setDoInput(false);
> // -----------------------
>
>                final long milliseconds;
>
>                try
>                {
>                        if (connection instanceof JarURLConnection)
>                        {
>                                JarURLConnection jarUrlConnection = 
> (JarURLConnection)connection;
>                                URL jarFileUrl = 
> jarUrlConnection.getJarFileURL();
>                                URLConnection jarFileConnection = 
> jarFileUrl.openConnection();
> // -----------------------
>                                jarFileConnection.setDoInput(false);
> // -----------------------
>                                // get timestamp from JAR
>                                milliseconds = 
> jarFileConnection.getLastModified();
>                        }
>                        else
>                        {
>                                // get timestamp from URL
>                                milliseconds = connection.getLastModified();
>                        }
>
>
>
> Am 08.08.2011 um 11:11 schrieb Martin Grigorov:
>
>> Please try to follow the development.
>> The first close was removed with
>> https://issues.apache.org/jira/browse/WICKET-3895 which will be
>> released with RC6, so this is not the problem here. In RC5.1 there
>> were two calls of close() and this caused some problems in WebLogic
>> container. Calling second close on
>> weblogic.utils.zip.SafeZipFileInputStream causes NPE.
>>
>> Maybe current trunk is not correct but here is how I see it: a
>> Connection is opened for the URL, then a check is made whether this
>> Connection is JarURLConnection and then #openConnection is called in
>> the jar's URL. At the end only the first connection is closed which
>> automatically should close the inner connection.
>>
>> If this is not correct then we need to close the inner (jar url's)
>> connection quietly. No need to dump exceptions while trying to close
>> the connections used only to get the last mtime.
>>
>> On Mon, Aug 8, 2011 at 11:56 AM, Peter Ertl <pe...@gmx.org> wrote:
>>> Well, there is no close statement for URLConnection!
>>>
>>> Just looking at a method named 'open' makes me automatically search for the 
>>> equivalent 'close' statement.
>>>
>>> Am 07.08.2011 um 20:03 schrieb Peter Ertl:
>>>
>>>> in Connection#getLastModified(String url), line 69 there's an
>>>>
>>>>                               URLConnection jarFileConnection = 
>>>> jarFileUrl.openConnection();
>>>>
>>>> without a close() statement...
>>>>
>>>> could that be the reason?
>>>>
>>>> Am 06.08.2011 um 00:21 schrieb rush66:
>>>>
>>>>> As per your suggestion I grabbed the project from SVN and compiled the
>>>>> snapshot. Sadly there was no change in my results.  Is there a bug that is
>>>>> already filed for this?
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> View this message in context: 
>>>>> http://apache-wicket.1842946.n4.nabble.com/CSS-JS-resource-file-handle-issues-tp3701938p3722413.html
>>>>> Sent from the Users forum mailing list archive at Nabble.com.
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>
>>>
>>
>>
>>
>> --
>> Martin Grigorov
>> jWeekend
>> Training, Consulting, Development
>> http://jWeekend.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>



-- 
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Reply via email to