Re: [apache/struts] WW-4920 fix java.net.JarURLConnection#parseSpecs (#209)

[Yasser Zamani]

On 2/20/2018 1:37 PM, Lukasz Lenart wrote:
> 2018-02-20 10:21 GMT+01:00 Yasser Zamani :
>>> This is not needed as the reload check was moved into
>>> FileManager#fileNeedsReloading methods - see usage of those methods.
>>
>> Yes I saw. However, FileManager#fileNeedsReloading method depends on if
>> `revision = files.get` is null or not i.e. depends on if the file is
>> under monitor or not, and as loadFile always calls monitorFile then
>> currently, every loaded file is under monitor regardless of if user has
>> set `struts.configuration.xml.reload` constant to true or not.
> 
> but FileManager#fileNeedsReloading won't be called if
> "struts.configuration.xml.reload" is set to false, see
> ConfigurationManager#conditionalReload

Thanks Łukasz! you were right. Then to sum up, Struts monitors all
loaded files regardless of devMode or "struts.configuration.xml.reload"
values (i.e. user may get a warning exception if framework was not able
to create a revision for loaded file). But Struts checks if reload is
needed only when "struts.configuration.xml.reload" constant is set to
true (devMode still doesn't make sense). Looks good to me however it
seems javadocs of FileManager interface should being fixed to satisfy these.

Regards.


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

Re: [apache/struts] WW-4920 fix java.net.JarURLConnection#parseSpecs (#209)

[Yasser Zamani]

On 2/20/2018 10:13 AM, Lukasz Lenart wrote:
> I moved discussion here to avoid notify other Apache committers. I think
> you should close the PR and open a new one :)

Yes I closed and also locked that :) I'm sorry and embarrassed if I
harmed Struts :( As a user, I wished GitHub at least show a warn message
when at-sign has such a lot of recipients.

> This is not needed as the reload check was moved into
> FileManager#fileNeedsReloading methods - see usage of those methods.

Yes I saw. However, FileManager#fileNeedsReloading method depends on if
`revision = files.get` is null or not i.e. depends on if the file is
under monitor or not, and as loadFile always calls monitorFile then
currently, every loaded file is under monitor regardless of if user has
set `struts.configuration.xml.reload` constant to true or not.

Regards.

Re: [apache/struts] WW-4920 fix java.net.JarURLConnection#parseSpecs (#209)

[Lukasz Lenart]

2018-02-20 10:21 GMT+01:00 Yasser Zamani :
>> This is not needed as the reload check was moved into
>> FileManager#fileNeedsReloading methods - see usage of those methods.
>
> Yes I saw. However, FileManager#fileNeedsReloading method depends on if
> `revision = files.get` is null or not i.e. depends on if the file is
> under monitor or not, and as loadFile always calls monitorFile then
> currently, every loaded file is under monitor regardless of if user has
> set `struts.configuration.xml.reload` constant to true or not.

but FileManager#fileNeedsReloading won't be called if
"struts.configuration.xml.reload" is set to false, see
ConfigurationManager#conditionalReload


Regards
-- 
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/

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

Re: [apache/struts] WW-4920 fix java.net.JarURLConnection#parseSpecs (#209)

[Lukasz Lenart]

2018-02-20 12:32 GMT+01:00 Yasser Zamani :
> Thanks Łukasz! you were right. Then to sum up, Struts monitors all
> loaded files regardless of devMode or "struts.configuration.xml.reload"
> values (i.e. user may get a warning exception if framework was not able
> to create a revision for loaded file). But Struts checks if reload is
> needed only when "struts.configuration.xml.reload" constant is set to
> true (devMode still doesn't make sense). Looks good to me however it
> seems javadocs of FileManager interface should being fixed to satisfy these.

"monitor" is a wrong word here, it keeps reference to the file ;-) I
would fix it as simple as possible and consider large refactor in 2.6.


Regards
-- 
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/

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

Save the date: ApacheCon North America, September 24-27 in Montréal

[Rich Bowen]

Dear Apache Enthusiast,

(You’re receiving this message because you’re subscribed to a user@ or 
dev@ list of one or more Apache Software Foundation projects.)


We’re pleased to announce the upcoming ApacheCon [1] in Montréal, 
September 24-27. This event is all about you — the Apache project community.


We’ll have four tracks of technical content this time, as well as lots 
of opportunities to connect with your project community, hack on the 
code, and learn about other related (and unrelated!) projects across the 
foundation.


The Call For Papers (CFP) [2] and registration are now open. Register 
early to take advantage of the early bird prices and secure your place 
at the event hotel.


Important dates
March 30: CFP closes
April 20: CFP notifications sent
	August 24: Hotel room block closes (please do not wait until the last 
minute)


Follow @ApacheCon on Twitter to be the first to hear announcements about 
keynotes, the schedule, evening events, and everything you can expect to 
see at the event.


See you in Montréal!

Sincerely, Rich Bowen, V.P. Events,
on behalf of the entire ApacheCon team

[1] http://www.apachecon.com/acna18
[2] https://cfp.apachecon.com/conference.html?apachecon-north-america-2018

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